From disman-admin@ietf.org Mon Jan 5 04:18:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08359 for ; Mon, 5 Jan 2004 04:18:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdQs6-0001hl-FB; Mon, 05 Jan 2004 04:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdQrb-0001er-UA for disman@optimus.ietf.org; Mon, 05 Jan 2004 04:17:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08320 for ; Mon, 5 Jan 2004 04:17:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdQrU-0004hh-00 for disman@ietf.org; Mon, 05 Jan 2004 04:17:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdQnf-0004ZN-00 for disman@ietf.org; Mon, 05 Jan 2004 04:13:28 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AdQkP-0004Sv-00 for disman@ietf.org; Mon, 05 Jan 2004 04:10:05 -0500 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i05996EC025371 for ; Mon, 5 Jan 2004 10:09:10 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 88486F6244 for ; Mon, 5 Jan 2004 10:09:05 +0100 (CET) From: Juergen Quittek To: disman@ietf.org Message-ID: <2147483647.1073297494@[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-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Disman] Check MIB module Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 05 Jan 2004 10:11:34 +0100 Content-Transfer-Encoding: 7bit Dear all, Happy new year! At NEC we tried to use a combination of the Event MIB and the Expression MIB for remote health check operations on a large set of small managed devices. We found the overhead of development cost, footprint and complexity of usage rather high for this application. Many nice features were hardly used, while a few were sufficient to fulfill most of our requirements. For most of our health checks we were fine with - a compare operation between an arbitrary managed object and a constant value - a logical AND operation over the results of all comparisons In the end we wrote a new MIB module, the Check MIB , with a hard coded AND operation and configurable compare operations. We added a few more features, such as a severity for each comparison, a notification mechanism, a list of failed comparisons and some means for dealing with situations were resources at small managed nodes are very limited. In the end the Check MIB turned out to be smaller and simpler than the individual Event MIB or the individual Expression MIB. Certainly, this is due to the fact that we concentrate on remote health check operations. We want to further develop and improve the Check MIB. Everybody who wants to join us is very welcome! I'm looking forward to your comments. 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.ccrle.nec.de From exim@www1.ietf.org Mon Jan 5 04:23:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08696 for ; Mon, 5 Jan 2004 04:23:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdQxF-0001wD-8s for disman-archive@odin.ietf.org; Mon, 05 Jan 2004 04:23:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i059NLR2007444 for disman-archive@odin.ietf.org; Mon, 5 Jan 2004 04:23:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdQxE-0001vz-DX for disman-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 04:23:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08571 for ; Mon, 5 Jan 2004 04:23:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdQxB-00056H-00 for disman-web-archive@ietf.org; Mon, 05 Jan 2004 04:23:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdQvM-0004tw-00 for disman-web-archive@ietf.org; Mon, 05 Jan 2004 04:21:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdQsN-0004jG-00 for disman-web-archive@ietf.org; Mon, 05 Jan 2004 04:18:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdQs6-0001hl-FB; Mon, 05 Jan 2004 04:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdQrb-0001er-UA for disman@optimus.ietf.org; Mon, 05 Jan 2004 04:17:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08320 for ; Mon, 5 Jan 2004 04:17:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdQrU-0004hh-00 for disman@ietf.org; Mon, 05 Jan 2004 04:17:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdQnf-0004ZN-00 for disman@ietf.org; Mon, 05 Jan 2004 04:13:28 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AdQkP-0004Sv-00 for disman@ietf.org; Mon, 05 Jan 2004 04:10:05 -0500 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i05996EC025371 for ; Mon, 5 Jan 2004 10:09:10 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 88486F6244 for ; Mon, 5 Jan 2004 10:09:05 +0100 (CET) From: Juergen Quittek To: disman@ietf.org Message-ID: <2147483647.1073297494@[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-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Disman] Check MIB module Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 05 Jan 2004 10:11:34 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, Happy new year! At NEC we tried to use a combination of the Event MIB and the Expression MIB for remote health check operations on a large set of small managed devices. We found the overhead of development cost, footprint and complexity of usage rather high for this application. Many nice features were hardly used, while a few were sufficient to fulfill most of our requirements. For most of our health checks we were fine with - a compare operation between an arbitrary managed object and a constant value - a logical AND operation over the results of all comparisons In the end we wrote a new MIB module, the Check MIB , with a hard coded AND operation and configurable compare operations. We added a few more features, such as a severity for each comparison, a notification mechanism, a list of failed comparisons and some means for dealing with situations were resources at small managed nodes are very limited. In the end the Check MIB turned out to be smaller and simpler than the individual Event MIB or the individual Expression MIB. Certainly, this is due to the fact that we concentrate on remote health check operations. We want to further develop and improve the Check MIB. Everybody who wants to join us is very welcome! I'm looking forward to your comments. 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.ccrle.nec.de From disman-admin@ietf.org Wed Jan 7 08:06:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07920 for ; Wed, 7 Jan 2004 08:06:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeDNp-0001q3-OG; Wed, 07 Jan 2004 08:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeDNE-0001pL-6V for disman@optimus.ietf.org; Wed, 07 Jan 2004 08:05:24 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07878; Wed, 7 Jan 2004 08:05:22 -0500 (EST) Message-Id: <200401071305.IAA07878@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-alarm-mib-17.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 07 Jan 2004 08:05:22 -0500 --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 : Alarm MIB Author(s) : S. Chisholm, D. Romascanu Filename : draft-ietf-disman-alarm-mib-17.txt Pages : 70 Date : 2004-1-6 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for defining and storing alarms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-17.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-alarm-mib-17.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-alarm-mib-17.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-1-6132136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-alarm-mib-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-alarm-mib-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-6132136.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Wed Jan 7 08:10:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08055 for ; Wed, 7 Jan 2004 08:10:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeDRf-0002G2-2t for disman-archive@odin.ietf.org; Wed, 07 Jan 2004 08:09:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07D9xd0008674 for disman-archive@odin.ietf.org; Wed, 7 Jan 2004 08:09:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeDRe-0002Fp-Vg for disman-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 08:09:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08018 for ; Wed, 7 Jan 2004 08:09:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeDRd-0001Mz-00 for disman-web-archive@ietf.org; Wed, 07 Jan 2004 08:09:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeDPj-0001HD-00 for disman-web-archive@ietf.org; Wed, 07 Jan 2004 08:08:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeDNu-0001CI-00 for disman-web-archive@ietf.org; Wed, 07 Jan 2004 08:06:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeDNp-0001q3-OG; Wed, 07 Jan 2004 08:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeDNE-0001pL-6V for disman@optimus.ietf.org; Wed, 07 Jan 2004 08:05:24 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07878; Wed, 7 Jan 2004 08:05:22 -0500 (EST) Message-Id: <200401071305.IAA07878@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-alarm-mib-17.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 07 Jan 2004 08:05:22 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Alarm MIB Author(s) : S. Chisholm, D. Romascanu Filename : draft-ietf-disman-alarm-mib-17.txt Pages : 70 Date : 2004-1-6 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for defining and storing alarms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-17.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-alarm-mib-17.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-alarm-mib-17.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-1-6132136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-alarm-mib-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-alarm-mib-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-6132136.I-D@ietf.org> --OtherAccess-- --NextPart-- From disman-admin@ietf.org Thu Jan 8 23:15:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28073 for ; Thu, 8 Jan 2004 23:15:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeo34-0007DF-2B; Thu, 08 Jan 2004 23:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeo2x-0007CW-ID for disman@optimus.ietf.org; Thu, 08 Jan 2004 23:14:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28018 for ; Thu, 8 Jan 2004 23:14:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeo2u-0001O0-00 for disman@ietf.org; Thu, 08 Jan 2004 23:14:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aenys-0001FK-00 for disman@ietf.org; Thu, 08 Jan 2004 23:10:43 -0500 Received: from bittern.mail.pas.earthlink.net ([207.217.120.119]) by ietf-mx with esmtp (Exim 4.12) id 1AenwI-00016n-00 for disman@ietf.org; Thu, 08 Jan 2004 23:08:02 -0500 Received: from h-68-165-65-142.snvacaid.dynamic.covad.net ([68.165.65.142] helo=oemcomputer) by bittern.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Aenvf-000619-00 for disman@ietf.org; Thu, 08 Jan 2004 20:07:24 -0800 Message-ID: <003f01c3d666$8d9275e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Disman] Fw: disman-alarm MIB Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Jan 2004 20:10:44 -0800 Hi - I'm forwarding part of an off-list discussion with the AD and editors of the Alarm MIB. The problem is that the registry procedures need to be clarified. Any constructive proposal would be appreciated. Follwing the extract of the discussion is my attempt at a clarification. > > > Another issue that came up today (From IANA) is that it > > > is not clear to them how they assign new values: > > > > > > IANAItuProbableCause ::= TEXTUAL-CONVENTION > > > STATUS current > > > DESCRIPTION > > > "ITU probable cause values. Duplicate values defined in X.733 > > > are appended with X733 to ensure uniqueness. Probable cause > > > value 0 is reserved for special purposes. > > > > > > The Internet Assigned Number Authority (IANA) is responsible > > > for the assignment of all Internet numbers, including > > > various SNMP-related numbers, and specifically, new > > > IANAItuProbableCause values. Values of > > > IANAItuProbableCause less than 1024 are reserved for causes > > > that correspond to ITU probable cause. IANAItuProbableCause > > > of 0 is reserved for special purposes and therefore cannot > > > be assigned. See http://www.iana.org" > > > > > > To me it sounds that ITU defines new values, and then when they ask > > > IANA, then IANA will add them. Is that how we envision this? > > > Should we mention ITU-SG 4 as the one to ask for such values? > > > > I believe the idea is that when new values are defined by the ITU community, > > someone who cares (we don't care who) will request the addition to the > > IANA-maintained TC. It is expected that the overwhelming majority of > > such requests will have ITU values less than 1024, and that, consequently, > > it will be possible to use the same value, even though, strictly speaking, > > doing so is not technically necessary. > > > > > Can we add some text w.r.t. the FCFS assignments as to why we do > > > not worry about possible overlap and that this is OK? > > > > I believe the idea is that requests that don't correspond to ITU assignments > > are to be handled FCFS, and in no case will such a non-ITU value be > > given an assignment less than 1024. > > > When you read your own answers above... does that not make it clear > to you that IANA will have a hard time to decide how to handle a > request for a new enumeration when they get one. > So can we propose clarifying text that will let IANA do the proper > thing without having to ask some IESG member? > > > > > In otehr words, are we sure nobody can screw us up one way or > > > another. We have had some bad expericence with large FCFS spaces > > > in the recent past. That is why it comes up. > > > > That is why I personally preferred "specification required", > > but there was no WG support for adding that requirement. > > > Do you want to check with WG if they want to change their mind > now that IESG member bring it up too? > > > > The above is a DISCUSS that we want fixed. Maybe by RFC-Ed note. > > > > That would be ok with me. > > > But I need proposed text please! Potentially to be checked by > WG as well, depending on what it is gonna say, Probably best > to post to WG and give them a day or two to react. ... Proposed clarification: The Internet Assigned Number Authority (IANA) is responsible for the assignment of new IANAItuProbableCause values. The value 0 is reserved for special purposes and MUST NOT be assigned. Values in the range 1 to 1023 are reserved for values assigned by the ITU for probable cause values in that same range. All other requests for values will be handled on a first-come, first served basis, starting with 1024. See http://www.iana.org Randy From exim@www1.ietf.org Thu Jan 8 23:19:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28194 for ; Thu, 8 Jan 2004 23:19:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeo6d-0007MY-2E for disman-archive@odin.ietf.org; Thu, 08 Jan 2004 23:18:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i094IgrN028299 for disman-archive@odin.ietf.org; Thu, 8 Jan 2004 23:18:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeo6c-0007MM-Di for disman-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 23:18:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28166 for ; Thu, 8 Jan 2004 23:18:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeo6a-0001cE-00 for disman-web-archive@ietf.org; Thu, 08 Jan 2004 23:18:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeo4o-0001Xk-00 for disman-web-archive@ietf.org; Thu, 08 Jan 2004 23:16:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aeo3D-0001SJ-00 for disman-web-archive@ietf.org; Thu, 08 Jan 2004 23:15:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeo34-0007DF-2B; Thu, 08 Jan 2004 23:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeo2x-0007CW-ID for disman@optimus.ietf.org; Thu, 08 Jan 2004 23:14:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28018 for ; Thu, 8 Jan 2004 23:14:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeo2u-0001O0-00 for disman@ietf.org; Thu, 08 Jan 2004 23:14:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aenys-0001FK-00 for disman@ietf.org; Thu, 08 Jan 2004 23:10:43 -0500 Received: from bittern.mail.pas.earthlink.net ([207.217.120.119]) by ietf-mx with esmtp (Exim 4.12) id 1AenwI-00016n-00 for disman@ietf.org; Thu, 08 Jan 2004 23:08:02 -0500 Received: from h-68-165-65-142.snvacaid.dynamic.covad.net ([68.165.65.142] helo=oemcomputer) by bittern.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Aenvf-000619-00 for disman@ietf.org; Thu, 08 Jan 2004 20:07:24 -0800 Message-ID: <003f01c3d666$8d9275e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Fw: disman-alarm MIB Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Jan 2004 20:10:44 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi - I'm forwarding part of an off-list discussion with the AD and editors of the Alarm MIB. The problem is that the registry procedures need to be clarified. Any constructive proposal would be appreciated. Follwing the extract of the discussion is my attempt at a clarification. > > > Another issue that came up today (From IANA) is that it > > > is not clear to them how they assign new values: > > > > > > IANAItuProbableCause ::= TEXTUAL-CONVENTION > > > STATUS current > > > DESCRIPTION > > > "ITU probable cause values. Duplicate values defined in X.733 > > > are appended with X733 to ensure uniqueness. Probable cause > > > value 0 is reserved for special purposes. > > > > > > The Internet Assigned Number Authority (IANA) is responsible > > > for the assignment of all Internet numbers, including > > > various SNMP-related numbers, and specifically, new > > > IANAItuProbableCause values. Values of > > > IANAItuProbableCause less than 1024 are reserved for causes > > > that correspond to ITU probable cause. IANAItuProbableCause > > > of 0 is reserved for special purposes and therefore cannot > > > be assigned. See http://www.iana.org" > > > > > > To me it sounds that ITU defines new values, and then when they ask > > > IANA, then IANA will add them. Is that how we envision this? > > > Should we mention ITU-SG 4 as the one to ask for such values? > > > > I believe the idea is that when new values are defined by the ITU community, > > someone who cares (we don't care who) will request the addition to the > > IANA-maintained TC. It is expected that the overwhelming majority of > > such requests will have ITU values less than 1024, and that, consequently, > > it will be possible to use the same value, even though, strictly speaking, > > doing so is not technically necessary. > > > > > Can we add some text w.r.t. the FCFS assignments as to why we do > > > not worry about possible overlap and that this is OK? > > > > I believe the idea is that requests that don't correspond to ITU assignments > > are to be handled FCFS, and in no case will such a non-ITU value be > > given an assignment less than 1024. > > > When you read your own answers above... does that not make it clear > to you that IANA will have a hard time to decide how to handle a > request for a new enumeration when they get one. > So can we propose clarifying text that will let IANA do the proper > thing without having to ask some IESG member? > > > > > In otehr words, are we sure nobody can screw us up one way or > > > another. We have had some bad expericence with large FCFS spaces > > > in the recent past. That is why it comes up. > > > > That is why I personally preferred "specification required", > > but there was no WG support for adding that requirement. > > > Do you want to check with WG if they want to change their mind > now that IESG member bring it up too? > > > > The above is a DISCUSS that we want fixed. Maybe by RFC-Ed note. > > > > That would be ok with me. > > > But I need proposed text please! Potentially to be checked by > WG as well, depending on what it is gonna say, Probably best > to post to WG and give them a day or two to react. ... Proposed clarification: The Internet Assigned Number Authority (IANA) is responsible for the assignment of new IANAItuProbableCause values. The value 0 is reserved for special purposes and MUST NOT be assigned. Values in the range 1 to 1023 are reserved for values assigned by the ITU for probable cause values in that same range. All other requests for values will be handled on a first-come, first served basis, starting with 1024. See http://www.iana.org Randy From disman-admin@ietf.org Fri Jan 9 08:32:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29292 for ; Fri, 9 Jan 2004 08:32:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aewk6-00061s-E6; Fri, 09 Jan 2004 08:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AewjR-0005yJ-SX for disman@optimus.ietf.org; Fri, 09 Jan 2004 08:31:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29225 for ; Fri, 9 Jan 2004 08:31:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AewjQ-0000Ux-00 for disman@ietf.org; Fri, 09 Jan 2004 08:31:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aewhu-0000I1-00 for disman@ietf.org; Fri, 09 Jan 2004 08:29:47 -0500 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 1Aewfi-0007Uj-00; Fri, 09 Jan 2004 08:27:30 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i09DQxJh157968; Fri, 9 Jan 2004 08:26:59 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i09DQxhd116896; Fri, 9 Jan 2004 06:26:59 -0700 In-Reply-To: <003f01c3d666$8d9275e0$7f1afea9@oemcomputer> To: "Randy Presuhn" Cc: "Disman \(E-mail\)" , disman-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Disman] Fw: disman-alarm MIB X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Robert Moore Message-ID: X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 01/09/2004 06:26:59, Serialize complete at 01/09/2004 06:26:59 Content-Type: multipart/alternative; boundary="=_alternative 0049FAC885256E16_=" 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=HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 9 Jan 2004 08:26:57 -0500 This is a multipart message in MIME format. --=_alternative 0049FAC885256E16_= Content-Type: text/plain; charset="US-ASCII" Randy, Obviously, I haven't been following these discussions closely. But to make sure everybody's on the same page, the text should say clearly which of the following types of requests IANA is supposed to honor for the FCFS range: (a) "I need *a* probable cause code point for METEOR STRIKE." (b) "I need you to assign code point x2000 to the probable cause METEOR STRIKE." When you say "All other requests for values ...," it's not clear whether requesting a value means (a), (b), or both. Regards, Bob Bob Moore WebSphere Advanced Design and Technology WebSphere Platform System House IBM Software Group +1-919-254-4436 remoore@us.ibm.com disman-admin@ietf.org wrote on 01/08/2004 11:10:44 PM: > Hi - > > I'm forwarding part of an off-list discussion with the AD and editors of the > Alarm MIB. The problem is that the registry procedures need to be clarified. > Any constructive proposal would be appreciated. Follwing the extract of > the discussion is my attempt at a clarification. > > > > > Another issue that came up today (From IANA) is that it > > > > is not clear to them how they assign new values: > > > > > > > > IANAItuProbableCause ::= TEXTUAL-CONVENTION > > > > STATUS current > > > > DESCRIPTION > > > > "ITU probable cause values. Duplicate values defined in X.733 > > > > are appended with X733 to ensure uniqueness. Probable cause > > > > value 0 is reserved for special purposes. > > > > > > > > The Internet Assigned Number Authority (IANA) is responsible > > > > for the assignment of all Internet numbers, including > > > > various SNMP-related numbers, and specifically, new > > > > IANAItuProbableCause values. Values of > > > > IANAItuProbableCause less than 1024 are reserved for causes > > > > that correspond to ITU probable cause. IANAItuProbableCause > > > > of 0 is reserved for special purposes and therefore cannot > > > > be assigned. See http://www.iana.org" > > > > > > > > To me it sounds that ITU defines new values, and then when they ask > > > > IANA, then IANA will add them. Is that how we envision this? > > > > Should we mention ITU-SG 4 as the one to ask for such values? > > > > > > I believe the idea is that when new values are defined by the ITU community, > > > someone who cares (we don't care who) will request the addition to the > > > IANA-maintained TC. It is expected that the overwhelming majority of > > > such requests will have ITU values less than 1024, and that, consequently, > > > it will be possible to use the same value, even though, strictly speaking, > > > doing so is not technically necessary. > > > > > > > Can we add some text w.r.t. the FCFS assignments as to why we do > > > > not worry about possible overlap and that this is OK? > > > > > > I believe the idea is that requests that don't correspond to ITU assignments > > > are to be handled FCFS, and in no case will such a non-ITU value be > > > given an assignment less than 1024. > > > > > When you read your own answers above... does that not make it clear > > to you that IANA will have a hard time to decide how to handle a > > request for a new enumeration when they get one. > > So can we propose clarifying text that will let IANA do the proper > > thing without having to ask some IESG member? > > > > > > > > In otehr words, are we sure nobody can screw us up one way or > > > > another. We have had some bad expericence with large FCFS spaces > > > > in the recent past. That is why it comes up. > > > > > > That is why I personally preferred "specification required", > > > but there was no WG support for adding that requirement. > > > > > Do you want to check with WG if they want to change their mind > > now that IESG member bring it up too? > > > > > > The above is a DISCUSS that we want fixed. Maybe by RFC-Ed note. > > > > > > That would be ok with me. > > > > > But I need proposed text please! Potentially to be checked by > > WG as well, depending on what it is gonna say, Probably best > > to post to WG and give them a day or two to react. > ... > > Proposed clarification: > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of new IANAItuProbableCause values. The > value 0 is reserved for special purposes and MUST NOT be > assigned. Values in the range 1 to 1023 are reserved for values > assigned by the ITU for probable cause values in that same range. > All other requests for values will be handled on a first-come, first served > basis, starting with 1024. See http://www.iana.org > > > Randy > > > --=_alternative 0049FAC885256E16_= Content-Type: text/html; charset="US-ASCII"
Randy,

Obviously, I haven't been following these discussions closely.  But to make sure everybody's on the same page, the text should say clearly which of the following types of requests IANA is supposed to honor for the FCFS range:

(a) "I need *a* probable cause code point for METEOR STRIKE."
(b) "I need you to assign code point x2000 to the probable cause METEOR STRIKE."

When you say "All other requests for values ...," it's not clear whether requesting a value means (a), (b), or both.

Regards,
Bob

Bob Moore
WebSphere Advanced Design and Technology
WebSphere Platform System House
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com

disman-admin@ietf.org wrote on 01/08/2004 11:10:44 PM:

> Hi -
>
> I'm forwarding part of an off-list discussion with the AD and editors of the
> Alarm MIB.  The problem is that the registry procedures need to be clarified.
> Any constructive proposal would be appreciated.  Follwing the extract of
> the discussion is my attempt at a clarification.
>
> > > > Another issue that came up today (From IANA) is that it
> > > > is not clear to them how they assign new values:
> > > >
> > > >    IANAItuProbableCause ::= TEXTUAL-CONVENTION
> > > >        STATUS current
> > > >        DESCRIPTION
> > > >            "ITU probable cause values. Duplicate values defined in X.733
> > > >            are appended with X733 to ensure uniqueness. Probable cause
> > > >            value 0 is reserved for special purposes.
> > > >
> > > >            The Internet Assigned Number Authority (IANA) is responsible
> > > >            for the assignment of all Internet numbers, including
> > > >            various SNMP-related numbers, and specifically, new
> > > >            IANAItuProbableCause values. Values of
> > > >            IANAItuProbableCause less than 1024 are reserved for causes
> > > >            that correspond to ITU probable cause. IANAItuProbableCause
> > > >            of 0 is reserved for special purposes and therefore cannot
> > > >            be assigned. See http://www.iana.org"
> > > >
> > > > To me it sounds that ITU defines new values, and then when they ask
> > > > IANA, then IANA will add them. Is that how we envision this?
> > > > Should we mention ITU-SG 4 as the one to ask for such values?
> > >
> > > I believe the idea is that when new values are defined by the ITU community,
> > > someone who cares (we don't care who) will request the addition to the
> > > IANA-maintained TC.  It is expected that the overwhelming majority of
> > > such requests will have ITU values less than 1024, and that, consequently,
> > > it will be possible to use the same value, even though, strictly speaking,
> > > doing so is not technically necessary.
> > >
> > > > Can we add some text w.r.t. the FCFS assignments as to why we do
> > > > not worry about possible overlap and that this is OK?
> > >
> > > I believe the idea is that requests that don't correspond to ITU assignments
> > > are to be handled FCFS, and in no case will such a non-ITU value be
> > > given an assignment less than 1024.
> > >
> > When you read your own answers above... does that not make it clear
> > to you that IANA will have a hard time to decide how to handle a
> > request for a new enumeration when they get one.
> > So can we propose clarifying text that will let IANA do the proper
> > thing without having to ask some IESG member?
> >
> >
> > > > In otehr words, are we sure nobody can screw us up one way or
> > > > another. We have had some bad expericence with large FCFS spaces
> > > > in the recent past. That is why  it comes up.
> > >
> > > That is why I personally preferred "specification required",
> > > but there was no WG support for adding that requirement.
> > >
> > Do you want to check with WG if they want to change their mind
> > now that IESG member bring it up too?
> >
> > > > The above is a DISCUSS that we want fixed. Maybe by RFC-Ed note.
> > >
> > > That would be ok with me.
> > >
> > But I need proposed text please! Potentially to be checked by
> > WG as well, depending on what it is gonna say, Probably best
> > to post to WG and give them a day or two to react.
> ...
>
> Proposed clarification:
>
> The Internet Assigned Number Authority (IANA) is responsible
> for the assignment of new IANAItuProbableCause values. The
> value 0 is reserved for special purposes and MUST NOT be
> assigned.  Values in the range 1 to 1023 are reserved for values
> assigned by the ITU for probable cause values in that same range.
> All other requests for values will be handled on a first-come, first served
> basis, starting with 1024.  See http://www.iana.org
>
>
> Randy
>
>
>
--=_alternative 0049FAC885256E16_=-- From exim@www1.ietf.org Fri Jan 9 08:49:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29650 for ; Fri, 9 Jan 2004 08:49:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aex0Z-0006oQ-6A for disman-archive@odin.ietf.org; Fri, 09 Jan 2004 08:49:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09Dn3l3026182 for disman-archive@odin.ietf.org; Fri, 9 Jan 2004 08:49:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aex0Z-0006oD-29 for disman-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 08:49:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29611 for ; Fri, 9 Jan 2004 08:49:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aex0X-0001bD-00 for disman-web-archive@ietf.org; Fri, 09 Jan 2004 08:49:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aewwg-0000sy-00 for disman-web-archive@ietf.org; Fri, 09 Jan 2004 08:45:04 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AewvB-0000oE-02 for disman-web-archive@ietf.org; Fri, 09 Jan 2004 08:43:29 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AewkA-0001g5-O2 for disman-web-archive@ietf.org; Fri, 09 Jan 2004 08:32:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aewk6-00061s-E6; Fri, 09 Jan 2004 08:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AewjR-0005yJ-SX for disman@optimus.ietf.org; Fri, 09 Jan 2004 08:31:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29225 for ; Fri, 9 Jan 2004 08:31:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AewjQ-0000Ux-00 for disman@ietf.org; Fri, 09 Jan 2004 08:31:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aewhu-0000I1-00 for disman@ietf.org; Fri, 09 Jan 2004 08:29:47 -0500 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 1Aewfi-0007Uj-00; Fri, 09 Jan 2004 08:27:30 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i09DQxJh157968; Fri, 9 Jan 2004 08:26:59 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i09DQxhd116896; Fri, 9 Jan 2004 06:26:59 -0700 In-Reply-To: <003f01c3d666$8d9275e0$7f1afea9@oemcomputer> To: "Randy Presuhn" Cc: "Disman \(E-mail\)" , disman-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Disman] Fw: disman-alarm MIB X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Robert Moore Message-ID: X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 01/09/2004 06:26:59, Serialize complete at 01/09/2004 06:26:59 Content-Type: multipart/alternative; boundary="=_alternative 0049FAC885256E16_=" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 9 Jan 2004 08:26:57 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 0049FAC885256E16_= Content-Type: text/plain; charset="US-ASCII" Randy, Obviously, I haven't been following these discussions closely. But to make sure everybody's on the same page, the text should say clearly which of the following types of requests IANA is supposed to honor for the FCFS range: (a) "I need *a* probable cause code point for METEOR STRIKE." (b) "I need you to assign code point x2000 to the probable cause METEOR STRIKE." When you say "All other requests for values ...," it's not clear whether requesting a value means (a), (b), or both. Regards, Bob Bob Moore WebSphere Advanced Design and Technology WebSphere Platform System House IBM Software Group +1-919-254-4436 remoore@us.ibm.com disman-admin@ietf.org wrote on 01/08/2004 11:10:44 PM: > Hi - > > I'm forwarding part of an off-list discussion with the AD and editors of the > Alarm MIB. The problem is that the registry procedures need to be clarified. > Any constructive proposal would be appreciated. Follwing the extract of > the discussion is my attempt at a clarification. > > > > > Another issue that came up today (From IANA) is that it > > > > is not clear to them how they assign new values: > > > > > > > > IANAItuProbableCause ::= TEXTUAL-CONVENTION > > > > STATUS current > > > > DESCRIPTION > > > > "ITU probable cause values. Duplicate values defined in X.733 > > > > are appended with X733 to ensure uniqueness. Probable cause > > > > value 0 is reserved for special purposes. > > > > > > > > The Internet Assigned Number Authority (IANA) is responsible > > > > for the assignment of all Internet numbers, including > > > > various SNMP-related numbers, and specifically, new > > > > IANAItuProbableCause values. Values of > > > > IANAItuProbableCause less than 1024 are reserved for causes > > > > that correspond to ITU probable cause. IANAItuProbableCause > > > > of 0 is reserved for special purposes and therefore cannot > > > > be assigned. See http://www.iana.org" > > > > > > > > To me it sounds that ITU defines new values, and then when they ask > > > > IANA, then IANA will add them. Is that how we envision this? > > > > Should we mention ITU-SG 4 as the one to ask for such values? > > > > > > I believe the idea is that when new values are defined by the ITU community, > > > someone who cares (we don't care who) will request the addition to the > > > IANA-maintained TC. It is expected that the overwhelming majority of > > > such requests will have ITU values less than 1024, and that, consequently, > > > it will be possible to use the same value, even though, strictly speaking, > > > doing so is not technically necessary. > > > > > > > Can we add some text w.r.t. the FCFS assignments as to why we do > > > > not worry about possible overlap and that this is OK? > > > > > > I believe the idea is that requests that don't correspond to ITU assignments > > > are to be handled FCFS, and in no case will such a non-ITU value be > > > given an assignment less than 1024. > > > > > When you read your own answers above... does that not make it clear > > to you that IANA will have a hard time to decide how to handle a > > request for a new enumeration when they get one. > > So can we propose clarifying text that will let IANA do the proper > > thing without having to ask some IESG member? > > > > > > > > In otehr words, are we sure nobody can screw us up one way or > > > > another. We have had some bad expericence with large FCFS spaces > > > > in the recent past. That is why it comes up. > > > > > > That is why I personally preferred "specification required", > > > but there was no WG support for adding that requirement. > > > > > Do you want to check with WG if they want to change their mind > > now that IESG member bring it up too? > > > > > > The above is a DISCUSS that we want fixed. Maybe by RFC-Ed note. > > > > > > That would be ok with me. > > > > > But I need proposed text please! Potentially to be checked by > > WG as well, depending on what it is gonna say, Probably best > > to post to WG and give them a day or two to react. > ... > > Proposed clarification: > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of new IANAItuProbableCause values. The > value 0 is reserved for special purposes and MUST NOT be > assigned. Values in the range 1 to 1023 are reserved for values > assigned by the ITU for probable cause values in that same range. > All other requests for values will be handled on a first-come, first served > basis, starting with 1024. See http://www.iana.org > > > Randy > > > --=_alternative 0049FAC885256E16_= Content-Type: text/html; charset="US-ASCII"
Randy,

Obviously, I haven't been following these discussions closely.  But to make sure everybody's on the same page, the text should say clearly which of the following types of requests IANA is supposed to honor for the FCFS range:

(a) "I need *a* probable cause code point for METEOR STRIKE."
(b) "I need you to assign code point x2000 to the probable cause METEOR STRIKE."

When you say "All other requests for values ...," it's not clear whether requesting a value means (a), (b), or both.

Regards,
Bob

Bob Moore
WebSphere Advanced Design and Technology
WebSphere Platform System House
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com

disman-admin@ietf.org wrote on 01/08/2004 11:10:44 PM:

> Hi -
>
> I'm forwarding part of an off-list discussion with the AD and editors of the
> Alarm MIB.  The problem is that the registry procedures need to be clarified.
> Any constructive proposal would be appreciated.  Follwing the extract of
> the discussion is my attempt at a clarification.
>
> > > > Another issue that came up today (From IANA) is that it
> > > > is not clear to them how they assign new values:
> > > >
> > > >    IANAItuProbableCause ::= TEXTUAL-CONVENTION
> > > >        STATUS current
> > > >        DESCRIPTION
> > > >            "ITU probable cause values. Duplicate values defined in X.733
> > > >            are appended with X733 to ensure uniqueness. Probable cause
> > > >            value 0 is reserved for special purposes.
> > > >
> > > >            The Internet Assigned Number Authority (IANA) is responsible
> > > >            for the assignment of all Internet numbers, including
> > > >            various SNMP-related numbers, and specifically, new
> > > >            IANAItuProbableCause values. Values of
> > > >            IANAItuProbableCause less than 1024 are reserved for causes
> > > >            that correspond to ITU probable cause. IANAItuProbableCause
> > > >            of 0 is reserved for special purposes and therefore cannot
> > > >            be assigned. See http://www.iana.org"
> > > >
> > > > To me it sounds that ITU defines new values, and then when they ask
> > > > IANA, then IANA will add them. Is that how we envision this?
> > > > Should we mention ITU-SG 4 as the one to ask for such values?
> > >
> > > I believe the idea is that when new values are defined by the ITU community,
> > > someone who cares (we don't care who) will request the addition to the
> > > IANA-maintained TC.  It is expected that the overwhelming majority of
> > > such requests will have ITU values less than 1024, and that, consequently,
> > > it will be possible to use the same value, even though, strictly speaking,
> > > doing so is not technically necessary.
> > >
> > > > Can we add some text w.r.t. the FCFS assignments as to why we do
> > > > not worry about possible overlap and that this is OK?
> > >
> > > I believe the idea is that requests that don't correspond to ITU assignments
> > > are to be handled FCFS, and in no case will such a non-ITU value be
> > > given an assignment less than 1024.
> > >
> > When you read your own answers above... does that not make it clear
> > to you that IANA will have a hard time to decide how to handle a
> > request for a new enumeration when they get one.
> > So can we propose clarifying text that will let IANA do the proper
> > thing without having to ask some IESG member?
> >
> >
> > > > In otehr words, are we sure nobody can screw us up one way or
> > > > another. We have had some bad expericence with large FCFS spaces
> > > > in the recent past. That is why  it comes up.
> > >
> > > That is why I personally preferred "specification required",
> > > but there was no WG support for adding that requirement.
> > >
> > Do you want to check with WG if they want to change their mind
> > now that IESG member bring it up too?
> >
> > > > The above is a DISCUSS that we want fixed. Maybe by RFC-Ed note.
> > >
> > > That would be ok with me.
> > >
> > But I need proposed text please! Potentially to be checked by
> > WG as well, depending on what it is gonna say, Probably best
> > to post to WG and give them a day or two to react.
> ...
>
> Proposed clarification:
>
> The Internet Assigned Number Authority (IANA) is responsible
> for the assignment of new IANAItuProbableCause values. The
> value 0 is reserved for special purposes and MUST NOT be
> assigned.  Values in the range 1 to 1023 are reserved for values
> assigned by the ITU for probable cause values in that same range.
> All other requests for values will be handled on a first-come, first served
> basis, starting with 1024.  See http://www.iana.org
>
>
> Randy
>
>
>
--=_alternative 0049FAC885256E16_=-- From mailman-admin@ietf.org Fri Jan 9 12:57:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18477 for ; Fri, 9 Jan 2004 12:57:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af0s8-0006lk-Fh for disman-archive@lists.ietf.org; Fri, 09 Jan 2004 12:56:36 -0500 Date: Fri, 09 Jan 2004 12:56:36 -0500 Message-ID: <20040109175636.9164.24005.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: disman-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, disman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for disman-archive@lists.ietf.org: List Password // URL ---- -------- disman@ietf.org hixour https://www1.ietf.org/mailman/options/disman/disman-archive%40lists.ietf.org From disman-admin@ietf.org Fri Jan 9 15:30:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10376 for ; Fri, 9 Jan 2004 15:30:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3Gc-0004zP-CT; Fri, 09 Jan 2004 15:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3Fk-0004yb-60 for disman@optimus.ietf.org; Fri, 09 Jan 2004 15:29:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10048 for ; Fri, 9 Jan 2004 15:29:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af3Fi-000157-00 for disman@ietf.org; Fri, 09 Jan 2004 15:29:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af31b-0006tb-00 for disman@ietf.org; Fri, 09 Jan 2004 15:14:32 -0500 Received: from cardinal.mail.pas.earthlink.net ([207.217.121.226]) by ietf-mx with esmtp (Exim 4.12) id 1Af2Rj-0005WN-00 for disman@ietf.org; Fri, 09 Jan 2004 14:37:27 -0500 Received: from h-68-164-155-52.snvacaid.dynamic.covad.net ([68.164.155.52] helo=oemcomputer) by cardinal.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Af2Ra-0003aY-00 for disman@ietf.org; Fri, 09 Jan 2004 11:37:18 -0800 Message-ID: <006d01c3d6e8$02553080$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] Fw: disman-alarm MIB X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 9 Jan 2004 11:37:25 -0800 Hi - > From: "Robert Moore" > To: "Randy Presuhn" > Cc: "Disman (E-mail)" ; > Sent: Friday, January 09, 2004 5:26 AM > Subject: Re: [Disman] Fw: disman-alarm MIB ... > Obviously, I haven't been following these discussions closely. But to > make sure everybody's on the same page, the text should say clearly which > of the following types of requests IANA is supposed to honor for the FCFS > range: > > (a) "I need *a* probable cause code point for METEOR STRIKE." Of course. > (b) "I need you to assign code point x2000 to the probable cause METEOR > STRIKE." I do not believe this was intended. The only reason for reserving a particular range of values for the ITU was convenience. > When you say "All other requests for values ...," it's not clear whether > requesting a value means (a), (b), or both. ... What I meant in my proposed clarification was that any request for a value, which did not correspond to an ITU-assigned value less than 1024, would be given an FCFS assignment, starting with 1024 and working up. So, if ITU goes beyond 1023, the TC value and the corresponding ITU value will likely be different. Clear as mud? Randy From exim@www1.ietf.org Fri Jan 9 15:39:24 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12998 for ; Fri, 9 Jan 2004 15:39:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3PD-0005y9-Ba for disman-archive@odin.ietf.org; Fri, 09 Jan 2004 15:38:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09Kctoq022939 for disman-archive@odin.ietf.org; Fri, 9 Jan 2004 15:38:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3PD-0005xu-76 for disman-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 15:38:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12944 for ; Fri, 9 Jan 2004 15:38:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af3PB-0003Sf-00 for disman-web-archive@ietf.org; Fri, 09 Jan 2004 15:38:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af3Lc-0002a1-00 for disman-web-archive@ietf.org; Fri, 09 Jan 2004 15:35:13 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Af3Gh-0001Fg-00 for disman-web-archive@ietf.org; Fri, 09 Jan 2004 15:30:07 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Af3Gi-0003zZ-TG for disman-web-archive@ietf.org; Fri, 09 Jan 2004 15:30:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3Gc-0004zP-CT; Fri, 09 Jan 2004 15:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3Fk-0004yb-60 for disman@optimus.ietf.org; Fri, 09 Jan 2004 15:29:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10048 for ; Fri, 9 Jan 2004 15:29:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af3Fi-000157-00 for disman@ietf.org; Fri, 09 Jan 2004 15:29:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af31b-0006tb-00 for disman@ietf.org; Fri, 09 Jan 2004 15:14:32 -0500 Received: from cardinal.mail.pas.earthlink.net ([207.217.121.226]) by ietf-mx with esmtp (Exim 4.12) id 1Af2Rj-0005WN-00 for disman@ietf.org; Fri, 09 Jan 2004 14:37:27 -0500 Received: from h-68-164-155-52.snvacaid.dynamic.covad.net ([68.164.155.52] helo=oemcomputer) by cardinal.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Af2Ra-0003aY-00 for disman@ietf.org; Fri, 09 Jan 2004 11:37:18 -0800 Message-ID: <006d01c3d6e8$02553080$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] Fw: disman-alarm MIB X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 9 Jan 2004 11:37:25 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi - > From: "Robert Moore" > To: "Randy Presuhn" > Cc: "Disman (E-mail)" ; > Sent: Friday, January 09, 2004 5:26 AM > Subject: Re: [Disman] Fw: disman-alarm MIB ... > Obviously, I haven't been following these discussions closely. But to > make sure everybody's on the same page, the text should say clearly which > of the following types of requests IANA is supposed to honor for the FCFS > range: > > (a) "I need *a* probable cause code point for METEOR STRIKE." Of course. > (b) "I need you to assign code point x2000 to the probable cause METEOR > STRIKE." I do not believe this was intended. The only reason for reserving a particular range of values for the ITU was convenience. > When you say "All other requests for values ...," it's not clear whether > requesting a value means (a), (b), or both. ... What I meant in my proposed clarification was that any request for a value, which did not correspond to an ITU-assigned value less than 1024, would be given an FCFS assignment, starting with 1024 and working up. So, if ITU goes beyond 1023, the TC value and the corresponding ITU value will likely be different. Clear as mud? Randy From disman-admin@ietf.org Fri Jan 9 19:52:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02276 for ; Fri, 9 Jan 2004 19:52:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af7M7-0000kN-U1; Fri, 09 Jan 2004 19:51:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af6EQ-00060O-5d for disman@optimus.ietf.org; Fri, 09 Jan 2004 18:39:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29173 for ; Fri, 9 Jan 2004 18:39:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af6EN-0004dw-00 for disman@ietf.org; Fri, 09 Jan 2004 18:39:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af6Ce-0004a8-00 for disman@ietf.org; Fri, 09 Jan 2004 18:38:08 -0500 Received: from postfix4-1.free.fr ([213.228.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1Af6Bk-0004VG-00 for disman@ietf.org; Fri, 09 Jan 2004 18:37:12 -0500 Received: from lucines (lns-th2-15-82-64-230-33.adsl.proxad.net [82.64.230.33]) by postfix4-1.free.fr (Postfix) with SMTP id 84CEA6A7C7 for ; Sat, 10 Jan 2004 00:37:11 +0100 (CET) Message-ID: <000d01c3d709$816df390$21e64052@lucines> From: "Claude Diallo" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C3D711.E2D7B870" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=DEAR_SOMETHING,HTML_40_50, HTML_MESSAGE autolearn=no version=2.60 Subject: [Disman] Alarm management standards & practices Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 10 Jan 2004 00:37:11 +0100 This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C3D711.E2D7B870 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear sir, I work in insurer company, in a risk control department. I have to prepare a presentation on alarm management in term of = instruments and human issues. This is regarding the safety aspect Could you please provide me with the information that I can use = (standards & practices). Best regards C. DIALLO ------=_NextPart_000_000A_01C3D711.E2D7B870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear sir,
I work in insurer company, in a risk = control=20 department.
I have to prepare a presentation on = alarm=20 management in term of instruments and human issues. This is regarding = the safety=20 aspect
Could you please provide me with the = information=20 that I can use (standards & practices).
Best regards
C. DIALLO
 
------=_NextPart_000_000A_01C3D711.E2D7B870-- From exim@www1.ietf.org Fri Jan 9 19:56:24 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02344 for ; Fri, 9 Jan 2004 19:56:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af7Pv-0000po-1e for disman-archive@odin.ietf.org; Fri, 09 Jan 2004 19:55:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0A0ttgl003207 for disman-archive@odin.ietf.org; Fri, 9 Jan 2004 19:55:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af7Pu-0000pe-UE for disman-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 19:55:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02326 for ; Fri, 9 Jan 2004 19:55:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af7Pt-0001LP-00 for disman-web-archive@ietf.org; Fri, 09 Jan 2004 19:55:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af7O1-0001Hu-00 for disman-web-archive@ietf.org; Fri, 09 Jan 2004 19:53:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Af7MA-0001Ej-00 for disman-web-archive@ietf.org; Fri, 09 Jan 2004 19:52:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af7M7-0000kN-U1; Fri, 09 Jan 2004 19:51:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af6EQ-00060O-5d for disman@optimus.ietf.org; Fri, 09 Jan 2004 18:39:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29173 for ; Fri, 9 Jan 2004 18:39:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af6EN-0004dw-00 for disman@ietf.org; Fri, 09 Jan 2004 18:39:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af6Ce-0004a8-00 for disman@ietf.org; Fri, 09 Jan 2004 18:38:08 -0500 Received: from postfix4-1.free.fr ([213.228.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1Af6Bk-0004VG-00 for disman@ietf.org; Fri, 09 Jan 2004 18:37:12 -0500 Received: from lucines (lns-th2-15-82-64-230-33.adsl.proxad.net [82.64.230.33]) by postfix4-1.free.fr (Postfix) with SMTP id 84CEA6A7C7 for ; Sat, 10 Jan 2004 00:37:11 +0100 (CET) Message-ID: <000d01c3d709$816df390$21e64052@lucines> From: "Claude Diallo" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C3D711.E2D7B870" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Alarm management standards & practices Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 10 Jan 2004 00:37:11 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,DEAR_SOMETHING,HTML_40_50, HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C3D711.E2D7B870 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear sir, I work in insurer company, in a risk control department. I have to prepare a presentation on alarm management in term of = instruments and human issues. This is regarding the safety aspect Could you please provide me with the information that I can use = (standards & practices). Best regards C. DIALLO ------=_NextPart_000_000A_01C3D711.E2D7B870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear sir,
I work in insurer company, in a risk = control=20 department.
I have to prepare a presentation on = alarm=20 management in term of instruments and human issues. This is regarding = the safety=20 aspect
Could you please provide me with the = information=20 that I can use (standards & practices).
Best regards
C. DIALLO
 
------=_NextPart_000_000A_01C3D711.E2D7B870-- From exim@www1.ietf.org Fri Jan 9 19:58:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02439 for ; Fri, 9 Jan 2004 19:58:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af7SG-0000sC-Mq for disman-archive@odin.ietf.org; Fri, 09 Jan 2004 19:58:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0A0wKGq003349 for disman-archive@odin.ietf.org; Fri, 9 Jan 2004 19:58:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3Mt-0005U7-C5 for disman-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 15:36:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02188 for ; Fri, 9 Jan 2004 15:00:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af2Yt-0000rP-00 for disman-web-archive@ietf.org; Fri, 09 Jan 2004 14:44:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af1n4-00076D-00 for disman-web-archive@ietf.org; Fri, 09 Jan 2004 13:55:28 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Af1GK-0007Zh-01 for disman-web-archive@ietf.org; Fri, 09 Jan 2004 13:21:36 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Af0kG-0006Zu-5u for disman-web-archive@ietf.org; Fri, 09 Jan 2004 12:48:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af0kE-0005pa-HD for disman-web-archive@ietf.org; Fri, 09 Jan 2004 12:48:26 -0500 Date: Fri, 09 Jan 2004 12:48:26 -0500 Message-ID: <20040109174826.9164.70064.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: disman-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, disman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for disman-web-archive@ietf.org: List Password // URL ---- -------- disman@ietf.org carehu https://www1.ietf.org/mailman/options/disman/disman-web-archive%40ietf.org From disman-admin@ietf.org Sat Jan 10 06:53:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02926 for ; Sat, 10 Jan 2004 06:53:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfHfp-0001RZ-6r; Sat, 10 Jan 2004 06:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfHf5-0001RC-Js for disman@optimus.ietf.org; Sat, 10 Jan 2004 06:52:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02911 for ; Sat, 10 Jan 2004 06:52:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AfHf1-0003Ea-00 for disman@ietf.org; Sat, 10 Jan 2004 06:52:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AfHdC-00037m-00 for disman@ietf.org; Sat, 10 Jan 2004 06:50:19 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1AfHbZ-00030I-00 for disman@ietf.org; Sat, 10 Jan 2004 06:48:37 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Sat, 10 Jan 2004 04:48:15 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: Cc: "Hemanth Kumar" , "Raja Shekar" , "Hemanth Yamijala" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part2A74E764.0__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Subject: [Disman] Fwd: [RMONMIB] - statistical sampling for columnar objects Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 10 Jan 2004 04:48:04 -0700 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part2A74E764.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello, I posted the following mail in the rmonmib wg. Thanks to Randy for suggeting me to post my mail ( see below) in this wg. Thanks, Shailaja. >>> Shailaja Yadawad 1/9/2004 4:37:53 PM >>> Hello, If one wants to use the usr history group mib definition for the columnar object, the user has to carry out the configuration separately for each instance. Also, the monitoring application invariably has to collect the history for all the instances. We have defined a new object definition using which one can collect the history on selected instances of a columnar object and also one can configure for the all the instances in one configuration setting. Does anyone in this group have also felt the above mentioned needs?. Regards, Shailaja. --=__Part2A74E764.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
Hello,
 
I posted the following mail in the rmonmib wg. Thanks to Randy for suggeting me to post my mail ( see below)  in this wg.
 
Thanks,
Shailaja.

>>> Shailaja Yadawad 1/9/2004 4:37:53 PM >>>
Hello,
 
If one wants to use the usr history group mib definition for the columnar object, the user has to carry out the configuration separately for each instance. Also, the monitoring application invariably has to collect the history for all the instances.
 
 
We have defined a new object definition using which one can collect the history on selected instances of a columnar object and also one can configure for the all the instances in one configuration setting.
 
Does anyone in this group have also felt the above mentioned needs?.
 
Regards,
Shailaja.
 
--=__Part2A74E764.0__=-- From exim@www1.ietf.org Sat Jan 10 06:56:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03101 for ; Sat, 10 Jan 2004 06:56:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfHiw-0001ey-J4 for disman-archive@odin.ietf.org; Sat, 10 Jan 2004 06:56:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0ABuEer006376 for disman-archive@odin.ietf.org; Sat, 10 Jan 2004 06:56:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfHiw-0001ek-CI for disman-web-archive@optimus.ietf.org; Sat, 10 Jan 2004 06:56:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03092 for ; Sat, 10 Jan 2004 06:56:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AfHis-0003Y9-00 for disman-web-archive@ietf.org; Sat, 10 Jan 2004 06:56:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AfHhK-0003SY-00 for disman-web-archive@ietf.org; Sat, 10 Jan 2004 06:54:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AfHfr-0003Ke-00 for disman-web-archive@ietf.org; Sat, 10 Jan 2004 06:53:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfHfp-0001RZ-6r; Sat, 10 Jan 2004 06:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfHf5-0001RC-Js for disman@optimus.ietf.org; Sat, 10 Jan 2004 06:52:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02911 for ; Sat, 10 Jan 2004 06:52:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AfHf1-0003Ea-00 for disman@ietf.org; Sat, 10 Jan 2004 06:52:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AfHdC-00037m-00 for disman@ietf.org; Sat, 10 Jan 2004 06:50:19 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1AfHbZ-00030I-00 for disman@ietf.org; Sat, 10 Jan 2004 06:48:37 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Sat, 10 Jan 2004 04:48:15 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: Cc: "Hemanth Kumar" , "Raja Shekar" , "Hemanth Yamijala" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part2A74E764.0__=" Subject: [Disman] Fwd: [RMONMIB] - statistical sampling for columnar objects Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 10 Jan 2004 04:48:04 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part2A74E764.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello, I posted the following mail in the rmonmib wg. Thanks to Randy for suggeting me to post my mail ( see below) in this wg. Thanks, Shailaja. >>> Shailaja Yadawad 1/9/2004 4:37:53 PM >>> Hello, If one wants to use the usr history group mib definition for the columnar object, the user has to carry out the configuration separately for each instance. Also, the monitoring application invariably has to collect the history for all the instances. We have defined a new object definition using which one can collect the history on selected instances of a columnar object and also one can configure for the all the instances in one configuration setting. Does anyone in this group have also felt the above mentioned needs?. Regards, Shailaja. --=__Part2A74E764.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
Hello,
 
I posted the following mail in the rmonmib wg. Thanks to Randy for suggeting me to post my mail ( see below)  in this wg.
 
Thanks,
Shailaja.

>>> Shailaja Yadawad 1/9/2004 4:37:53 PM >>>
Hello,
 
If one wants to use the usr history group mib definition for the columnar object, the user has to carry out the configuration separately for each instance. Also, the monitoring application invariably has to collect the history for all the instances.
 
 
We have defined a new object definition using which one can collect the history on selected instances of a columnar object and also one can configure for the all the instances in one configuration setting.
 
Does anyone in this group have also felt the above mentioned needs?.
 
Regards,
Shailaja.
 
--=__Part2A74E764.0__=-- From disman-admin@ietf.org Mon Jan 12 18:51:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00041 for ; Mon, 12 Jan 2004 18:51:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgBpl-0002NH-U6; Mon, 12 Jan 2004 18:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgBov-0002LW-Uj for disman@optimus.ietf.org; Mon, 12 Jan 2004 18:50:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00027 for ; Mon, 12 Jan 2004 18:50:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgBos-000238-00 for disman@ietf.org; Mon, 12 Jan 2004 18:50:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgBmx-0001ys-00 for disman@ietf.org; Mon, 12 Jan 2004 18:48:07 -0500 Received: from gull.mail.pas.earthlink.net ([207.217.120.84]) by ietf-mx with esmtp (Exim 4.12) id 1AgBll-0001wa-00 for disman@ietf.org; Mon, 12 Jan 2004 18:46:53 -0500 Received: from h-68-164-159-253.snvacaid.dynamic.covad.net ([68.164.159.253] helo=oemcomputer) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AgBlk-0003jn-00 for disman@ietf.org; Mon, 12 Jan 2004 15:46:52 -0800 Message-ID: <00c801c3d966$5f2bbf60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Disman] submitting -00- disman drafts? Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Jan 2004 15:46:59 -0800 Hi - If you're planning to submit -00- internet drafts, and it would be appropriate for them to bear the draft-ietf-disman- string in their names, and you would like to avoid delays in their processing, please let me know by Friday of this week so I can inform the secretariat. My internet access from January 17 to February 2 will be rather limited, if there is any at all. Likewise, non-subscriber posts to the WG mailing list may be delayed during that time. Randy disman WG chair From exim@www1.ietf.org Mon Jan 12 18:54:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00195 for ; Mon, 12 Jan 2004 18:54:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgBsx-0002VU-0J for disman-archive@odin.ietf.org; Mon, 12 Jan 2004 18:54:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CNsIJk009632 for disman-archive@odin.ietf.org; Mon, 12 Jan 2004 18:54:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgBsw-0002VH-SI for disman-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 18:54:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00189 for ; Mon, 12 Jan 2004 18:54:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgBst-0002Gy-00 for disman-web-archive@ietf.org; Mon, 12 Jan 2004 18:54:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgBr3-0002BY-00 for disman-web-archive@ietf.org; Mon, 12 Jan 2004 18:52:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgBpp-00026U-00 for disman-web-archive@ietf.org; Mon, 12 Jan 2004 18:51:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgBpl-0002NH-U6; Mon, 12 Jan 2004 18:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgBov-0002LW-Uj for disman@optimus.ietf.org; Mon, 12 Jan 2004 18:50:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00027 for ; Mon, 12 Jan 2004 18:50:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgBos-000238-00 for disman@ietf.org; Mon, 12 Jan 2004 18:50:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgBmx-0001ys-00 for disman@ietf.org; Mon, 12 Jan 2004 18:48:07 -0500 Received: from gull.mail.pas.earthlink.net ([207.217.120.84]) by ietf-mx with esmtp (Exim 4.12) id 1AgBll-0001wa-00 for disman@ietf.org; Mon, 12 Jan 2004 18:46:53 -0500 Received: from h-68-164-159-253.snvacaid.dynamic.covad.net ([68.164.159.253] helo=oemcomputer) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AgBlk-0003jn-00 for disman@ietf.org; Mon, 12 Jan 2004 15:46:52 -0800 Message-ID: <00c801c3d966$5f2bbf60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] submitting -00- disman drafts? Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Jan 2004 15:46:59 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi - If you're planning to submit -00- internet drafts, and it would be appropriate for them to bear the draft-ietf-disman- string in their names, and you would like to avoid delays in their processing, please let me know by Friday of this week so I can inform the secretariat. My internet access from January 17 to February 2 will be rather limited, if there is any at all. Likewise, non-subscriber posts to the WG mailing list may be delayed during that time. Randy disman WG chair From disman-admin@ietf.org Tue Jan 13 06:21:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06731 for ; Tue, 13 Jan 2004 06:21:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgMbW-0000Yz-Ho; Tue, 13 Jan 2004 06:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgMah-0000X3-OG for disman@optimus.ietf.org; Tue, 13 Jan 2004 06:20:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06702 for ; Tue, 13 Jan 2004 06:20:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgMad-0007Hk-00 for disman@ietf.org; Tue, 13 Jan 2004 06:20:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgMYi-0007E7-00 for disman@ietf.org; Tue, 13 Jan 2004 06:18:09 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AgMWm-00078D-00 for disman@ietf.org; Tue, 13 Jan 2004 06:16:08 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0DBFcR04533 for ; Tue, 13 Jan 2004 06:15:39 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Jan 2004 06:15:38 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409C67291@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Disman] Issues from IESG Alarm MIB Review Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Jan 2004 06:15:38 -0500 Hi I will propose resolutions to these in separate emails. IESG-1 "Another issue that came up today (From IANA) is that it is not clear to them how they assign new values: IANAItuProbableCause ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "ITU probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAItuProbableCause values. Values of IANAItuProbableCause less than 1024 are reserved for causes that correspond to ITU probable cause. IANAItuProbableCause of 0 is reserved for special purposes and therefore cannot be assigned. See http://www.iana.org" To me it sounds that ITU defines new values, and then when they ask IANA, then IANA will add them. Is that how we envision this? Should we mention ITU-SG 4 as the one to ask for such values? Can we add some text w.r.t. the FCFS assignments as to why we do not worry about possible overlap and that this is OK? In otehr words, are we sure nobody can screw us up one way or another. We have had some bad expericence with large FCFS spaces in the recent past. That is why it comes up." IESG-2 "In the Terminology section, the draft says: Alarm Clear The detection that the fault indicated by an alarm no longer exists. A Notification SHOULD be sent on alarm clear. I'm a bit concerned about imposing a requirement like this in the terminology section. Is a better place to impose this available?" IESG-3 "In Section 3.4, the draft says: Security for alarms is awkward since access control for the objects in the underlying Notifications can be checked only where the Notification is created. Thus such checking is possible only for locally generated Notifications, and even then only when security credentials are available. This is very hard to parse, since it is difficult to understand whether the kind of security we're talking about is access control for the alarms themselves, access control to which Notifications refer, or something. It would help me, I think, if it said "for this $THREAT, there are the following issues"." IESG-4 "typo in the IANA Considerations -- "Values of IANAProbableCause greater than 1024" should be IANAItuProbableCause"" IESG-5 "As far as allowing the ones over 1024 to be assigned FCFS, is this a good idea? What if ITU assigns them in a future document?" In addition, there was an issue found that in the ITU Alarm MIB counter32 is defined but not used. I will call that Other-1 Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From exim@www1.ietf.org Tue Jan 13 06:24:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06888 for ; Tue, 13 Jan 2004 06:24:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgMep-0000rg-VT for disman-archive@odin.ietf.org; Tue, 13 Jan 2004 06:24:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DBORUD003323 for disman-archive@odin.ietf.org; Tue, 13 Jan 2004 06:24:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgMep-0000rW-Ks for disman-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 06:24:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06841 for ; Tue, 13 Jan 2004 06:24:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgMel-0007SW-00 for disman-web-archive@ietf.org; Tue, 13 Jan 2004 06:24:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgMco-0007O7-00 for disman-web-archive@ietf.org; Tue, 13 Jan 2004 06:22:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgMbW-0007KS-00 for disman-web-archive@ietf.org; Tue, 13 Jan 2004 06:21:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgMbW-0000Yz-Ho; Tue, 13 Jan 2004 06:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgMah-0000X3-OG for disman@optimus.ietf.org; Tue, 13 Jan 2004 06:20:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06702 for ; Tue, 13 Jan 2004 06:20:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgMad-0007Hk-00 for disman@ietf.org; Tue, 13 Jan 2004 06:20:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgMYi-0007E7-00 for disman@ietf.org; Tue, 13 Jan 2004 06:18:09 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AgMWm-00078D-00 for disman@ietf.org; Tue, 13 Jan 2004 06:16:08 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0DBFcR04533 for ; Tue, 13 Jan 2004 06:15:39 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Jan 2004 06:15:38 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409C67291@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Disman] Issues from IESG Alarm MIB Review Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Jan 2004 06:15:38 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi I will propose resolutions to these in separate emails. IESG-1 "Another issue that came up today (From IANA) is that it is not clear to them how they assign new values: IANAItuProbableCause ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "ITU probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAItuProbableCause values. Values of IANAItuProbableCause less than 1024 are reserved for causes that correspond to ITU probable cause. IANAItuProbableCause of 0 is reserved for special purposes and therefore cannot be assigned. See http://www.iana.org" To me it sounds that ITU defines new values, and then when they ask IANA, then IANA will add them. Is that how we envision this? Should we mention ITU-SG 4 as the one to ask for such values? Can we add some text w.r.t. the FCFS assignments as to why we do not worry about possible overlap and that this is OK? In otehr words, are we sure nobody can screw us up one way or another. We have had some bad expericence with large FCFS spaces in the recent past. That is why it comes up." IESG-2 "In the Terminology section, the draft says: Alarm Clear The detection that the fault indicated by an alarm no longer exists. A Notification SHOULD be sent on alarm clear. I'm a bit concerned about imposing a requirement like this in the terminology section. Is a better place to impose this available?" IESG-3 "In Section 3.4, the draft says: Security for alarms is awkward since access control for the objects in the underlying Notifications can be checked only where the Notification is created. Thus such checking is possible only for locally generated Notifications, and even then only when security credentials are available. This is very hard to parse, since it is difficult to understand whether the kind of security we're talking about is access control for the alarms themselves, access control to which Notifications refer, or something. It would help me, I think, if it said "for this $THREAT, there are the following issues"." IESG-4 "typo in the IANA Considerations -- "Values of IANAProbableCause greater than 1024" should be IANAItuProbableCause"" IESG-5 "As far as allowing the ones over 1024 to be assigned FCFS, is this a good idea? What if ITU assigns them in a future document?" In addition, there was an issue found that in the ITU Alarm MIB counter32 is defined but not used. I will call that Other-1 Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From disman-admin@ietf.org Tue Jan 13 09:49:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14846 for ; Tue, 13 Jan 2004 09:49:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgPqm-00087b-LN; Tue, 13 Jan 2004 09:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgPqM-000873-Cv for disman@optimus.ietf.org; Tue, 13 Jan 2004 09:48:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14781 for ; Tue, 13 Jan 2004 09:48:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgPqK-0002nw-00 for disman@ietf.org; Tue, 13 Jan 2004 09:48:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgPoI-0002V7-00 for disman@ietf.org; Tue, 13 Jan 2004 09:46:27 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AgPme-0002Je-00 for disman@ietf.org; Tue, 13 Jan 2004 09:44:44 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0DEiC623542 for ; Tue, 13 Jan 2004 09:44:12 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Jan 2004 09:44:12 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409C673DB@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Disman] Proposed Resolutions to iesg-2, iesg-3, iesg-4 and other-1 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Jan 2004 09:44:09 -0500 Hi ------------------- The following is the proposed resolution to iesg-2 Replace " Alarm Clear The detection that the fault indicated by an alarm no longer exists. A Notification SHOULD be sent on alarm clear." With " Alarm Clear The detection that the fault indicated by an alarm no longer exists. " And add the following text at the end of the first paragraph in 3.3.2. " Alarms SHOULD be modelled so Notification are sent on alarm clear." ------------------- The following is the proposed resolution to iesg-3. In section 3.4 replace " Security for alarms is awkward since access control for the objects in the underlying Notifications can be checked only where the Notification is created. Thus such checking is possible only for locally generated Notifications, and even then only when security credentials are available." " Given the nature of VACM, security for alarms is awkward since access control for the objects in the underlying Notifications can be checked only where the Notification is created. Thus such checking is possible only for locally generated Notifications, and even then only when security credentials are available." ------------------- The following is the proposed resolution to iesg-4. Replace "assigned. Values of IANAProbableCause greater than 1024 may be" With "assigned. Values of IANAItuProbableCause greater than 1024 may be" -------------------- The following is the proposed resolution to other-1 Remove couter32 from the imports in the ITU-ALARM-MIB ---------------------------- Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From exim@www1.ietf.org Tue Jan 13 09:54:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15253 for ; Tue, 13 Jan 2004 09:54:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgPw2-00009O-OJ for disman-archive@odin.ietf.org; Tue, 13 Jan 2004 09:54:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DEsQp1000572 for disman-archive@odin.ietf.org; Tue, 13 Jan 2004 09:54:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgPw2-000095-Gj for disman-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 09:54:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15211 for ; Tue, 13 Jan 2004 09:54:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgPw0-0003gn-00 for disman-web-archive@ietf.org; Tue, 13 Jan 2004 09:54:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgPt4-0003Dr-00 for disman-web-archive@ietf.org; Tue, 13 Jan 2004 09:51:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgPqp-0002sK-00 for disman-web-archive@ietf.org; Tue, 13 Jan 2004 09:49:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgPqm-00087b-LN; Tue, 13 Jan 2004 09:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgPqM-000873-Cv for disman@optimus.ietf.org; Tue, 13 Jan 2004 09:48:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14781 for ; Tue, 13 Jan 2004 09:48:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgPqK-0002nw-00 for disman@ietf.org; Tue, 13 Jan 2004 09:48:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgPoI-0002V7-00 for disman@ietf.org; Tue, 13 Jan 2004 09:46:27 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AgPme-0002Je-00 for disman@ietf.org; Tue, 13 Jan 2004 09:44:44 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0DEiC623542 for ; Tue, 13 Jan 2004 09:44:12 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Jan 2004 09:44:12 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409C673DB@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Disman] Proposed Resolutions to iesg-2, iesg-3, iesg-4 and other-1 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Jan 2004 09:44:09 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi ------------------- The following is the proposed resolution to iesg-2 Replace " Alarm Clear The detection that the fault indicated by an alarm no longer exists. A Notification SHOULD be sent on alarm clear." With " Alarm Clear The detection that the fault indicated by an alarm no longer exists. " And add the following text at the end of the first paragraph in 3.3.2. " Alarms SHOULD be modelled so Notification are sent on alarm clear." ------------------- The following is the proposed resolution to iesg-3. In section 3.4 replace " Security for alarms is awkward since access control for the objects in the underlying Notifications can be checked only where the Notification is created. Thus such checking is possible only for locally generated Notifications, and even then only when security credentials are available." " Given the nature of VACM, security for alarms is awkward since access control for the objects in the underlying Notifications can be checked only where the Notification is created. Thus such checking is possible only for locally generated Notifications, and even then only when security credentials are available." ------------------- The following is the proposed resolution to iesg-4. Replace "assigned. Values of IANAProbableCause greater than 1024 may be" With "assigned. Values of IANAItuProbableCause greater than 1024 may be" -------------------- The following is the proposed resolution to other-1 Remove couter32 from the imports in the ITU-ALARM-MIB ---------------------------- Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From disman-admin@ietf.org Wed Jan 14 07:01:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14586 for ; Wed, 14 Jan 2004 07:01:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agjhl-000347-Nc; Wed, 14 Jan 2004 07:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgjhP-00032h-7j for disman@optimus.ietf.org; Wed, 14 Jan 2004 07:00:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14486 for ; Wed, 14 Jan 2004 07:00:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgjhL-0007bb-00 for disman@ietf.org; Wed, 14 Jan 2004 07:00:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgjfW-0007Ub-00 for disman@ietf.org; Wed, 14 Jan 2004 06:58:43 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1Agjdm-0007CM-00 for disman@ietf.org; Wed, 14 Jan 2004 06:56:54 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Wed, 14 Jan 2004 04:56:32 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: Cc: "Hemanth Kumar" , "Raja Shekar" , "Hemanth Yamijala" Subject: [Disman] Regarding the draft submission on the Object definition for the history collection Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part4D6C054E.0__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Jan 2004 04:56:14 -0700 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part4D6C054E.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi All, We have prepared a draft on object definition for history collection of Data( ASN.1 integer based) and want to submit the same to "WG" for review. The proposed object definition has similarity to the user history group of the RMON2(RFC2021) but draft proposal is not intending the extension of the user history group but instead proposes a stand alone MIB definition. The question that I have is, do we submit such a draft in this WG (Disman) or Rmonmib WG ?. At the end of this mail I have appended a introduction part of our draft. Regards, Shailaja. Draft Introduction __________________________________________________________ Object definition for history collection is a difficult task for a number of reasons. Firstly, object definition must allow the user to specify any Data(an ASN.1 INTEGER based object) for history collection. Secondly, the object definition should allow the user to configure and control history collection with one configuration settings for the entire columnar object. Also the object definition should provide selection of one or more instances for the history collection of the given columnar Data. As the need for alarm generation forms a part of monitoring the user requires a object definition provision for configuring the alarm generation as well. Some of these above mentioned challenges, such as user specific history collection and alarm generation is being addressed by the IETF working group, Remote Network Monitoring,rmonmib. As there are several challenges the user faces while configuring for the monitoring using the available standard object definitions, the user needs detailed configuration and control of the history collection. This document proposes the object definition for a sophisticated and easy form for configuration and control of history collection. ____________________________________________________________ --=__Part4D6C054E.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
Hi All,
 
We have prepared a draft on object definition for history collection of Data( ASN.1 integer based) and want to submit the same to "WG" for review.
 
The proposed object definition has  similarity to the user history group of the RMON2(RFC2021) but draft proposal is not intending the extension of the user history group but instead proposes a stand alone MIB definition.
 
The question that I have is, do we submit such a draft  in this WG (Disman) or Rmonmib WG ?.
At the end of this mail I have appended a introduction part of our draft.
 
Regards,
Shailaja.
 
 
 
Draft Introduction
__________________________________________________________
 
Object definition for history collection is a difficult task for a number of reasons.
Firstly, object definition must allow the user to specify any
Data(an ASN.1 INTEGER based object) for history collection. Secondly, the object
definition should allow the user to configure and control history collection with
one configuration settings for the entire columnar object. Also the object definition
should provide selection of one or more instances for the history collection of the
given columnar Data. As the need for alarm generation forms a part of monitoring
the user requires a object definition provision for configuring the alarm generation
as well.
 
Some of these above mentioned challenges, such as user specific history
collection and alarm generation is being addressed by the IETF working group,
Remote Network Monitoring,rmonmib. As there are several challenges the user
faces while configuring for the monitoring using the available standard object
definitions, the user needs detailed configuration and control of the history
collection. This document proposes the object definition for a sophisticated
and easy form for configuration and control of history collection.
____________________________________________________________
--=__Part4D6C054E.0__=-- From exim@www1.ietf.org Wed Jan 14 07:05:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14718 for ; Wed, 14 Jan 2004 07:05:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgjlI-0003Db-CD for disman-archive@odin.ietf.org; Wed, 14 Jan 2004 07:04:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EC4esV012370 for disman-archive@odin.ietf.org; Wed, 14 Jan 2004 07:04:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgjlI-0003DR-8u for disman-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 07:04:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14705 for ; Wed, 14 Jan 2004 07:04:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgjlE-0007mJ-00 for disman-web-archive@ietf.org; Wed, 14 Jan 2004 07:04:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgjjM-0007ix-00 for disman-web-archive@ietf.org; Wed, 14 Jan 2004 07:02:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Agjhm-0007ef-00 for disman-web-archive@ietf.org; Wed, 14 Jan 2004 07:01:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agjhl-000347-Nc; Wed, 14 Jan 2004 07:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgjhP-00032h-7j for disman@optimus.ietf.org; Wed, 14 Jan 2004 07:00:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14486 for ; Wed, 14 Jan 2004 07:00:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgjhL-0007bb-00 for disman@ietf.org; Wed, 14 Jan 2004 07:00:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgjfW-0007Ub-00 for disman@ietf.org; Wed, 14 Jan 2004 06:58:43 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1Agjdm-0007CM-00 for disman@ietf.org; Wed, 14 Jan 2004 06:56:54 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Wed, 14 Jan 2004 04:56:32 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: Cc: "Hemanth Kumar" , "Raja Shekar" , "Hemanth Yamijala" Subject: [Disman] Regarding the draft submission on the Object definition for the history collection Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part4D6C054E.0__=" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Jan 2004 04:56:14 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part4D6C054E.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi All, We have prepared a draft on object definition for history collection of Data( ASN.1 integer based) and want to submit the same to "WG" for review. The proposed object definition has similarity to the user history group of the RMON2(RFC2021) but draft proposal is not intending the extension of the user history group but instead proposes a stand alone MIB definition. The question that I have is, do we submit such a draft in this WG (Disman) or Rmonmib WG ?. At the end of this mail I have appended a introduction part of our draft. Regards, Shailaja. Draft Introduction __________________________________________________________ Object definition for history collection is a difficult task for a number of reasons. Firstly, object definition must allow the user to specify any Data(an ASN.1 INTEGER based object) for history collection. Secondly, the object definition should allow the user to configure and control history collection with one configuration settings for the entire columnar object. Also the object definition should provide selection of one or more instances for the history collection of the given columnar Data. As the need for alarm generation forms a part of monitoring the user requires a object definition provision for configuring the alarm generation as well. Some of these above mentioned challenges, such as user specific history collection and alarm generation is being addressed by the IETF working group, Remote Network Monitoring,rmonmib. As there are several challenges the user faces while configuring for the monitoring using the available standard object definitions, the user needs detailed configuration and control of the history collection. This document proposes the object definition for a sophisticated and easy form for configuration and control of history collection. ____________________________________________________________ --=__Part4D6C054E.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
Hi All,
 
We have prepared a draft on object definition for history collection of Data( ASN.1 integer based) and want to submit the same to "WG" for review.
 
The proposed object definition has  similarity to the user history group of the RMON2(RFC2021) but draft proposal is not intending the extension of the user history group but instead proposes a stand alone MIB definition.
 
The question that I have is, do we submit such a draft  in this WG (Disman) or Rmonmib WG ?.
At the end of this mail I have appended a introduction part of our draft.
 
Regards,
Shailaja.
 
 
 
Draft Introduction
__________________________________________________________
 
Object definition for history collection is a difficult task for a number of reasons.
Firstly, object definition must allow the user to specify any
Data(an ASN.1 INTEGER based object) for history collection. Secondly, the object
definition should allow the user to configure and control history collection with
one configuration settings for the entire columnar object. Also the object definition
should provide selection of one or more instances for the history collection of the
given columnar Data. As the need for alarm generation forms a part of monitoring
the user requires a object definition provision for configuring the alarm generation
as well.
 
Some of these above mentioned challenges, such as user specific history
collection and alarm generation is being addressed by the IETF working group,
Remote Network Monitoring,rmonmib. As there are several challenges the user
faces while configuring for the monitoring using the available standard object
definitions, the user needs detailed configuration and control of the history
collection. This document proposes the object definition for a sophisticated
and easy form for configuration and control of history collection.
____________________________________________________________
--=__Part4D6C054E.0__=-- From disman-admin@ietf.org Wed Jan 14 07:39:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15456 for ; Wed, 14 Jan 2004 07:39:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgkIX-0004xZ-01; Wed, 14 Jan 2004 07:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgkHi-0004uj-3y for disman@optimus.ietf.org; Wed, 14 Jan 2004 07:38:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15431 for ; Wed, 14 Jan 2004 07:38:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgkHX-00016L-00 for disman@ietf.org; Wed, 14 Jan 2004 07:37:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgkCd-0000vY-00 for disman@ietf.org; Wed, 14 Jan 2004 07:32:55 -0500 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by ietf-mx with esmtp (Exim 4.12) id 1Agk74-0000lG-00 for disman@ietf.org; Wed, 14 Jan 2004 07:27:10 -0500 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0ECQfIV024672 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 14 Jan 2004 13:26:41 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0ECQfCw024365; Wed, 14 Jan 2004 13:26:41 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) id i0ECQfRM024362; Wed, 14 Jan 2004 13:26:41 +0100 Message-Id: <200401141226.i0ECQfRM024362@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: yshailaja@novell.com CC: disman@ietf.org, HeKumar@novell.com, RShekar@novell.com, YHemanth@novell.com In-reply-to: (yshailaja@novell.com) Subject: Re: [Disman] Regarding the draft submission on the Object definition for the history collection References: X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Jan 2004 13:26:41 +0100 >>>>> Shailaja Yadawad writes: Shailaja> We have prepared a draft on object definition for history Shailaja> collection of Data( ASN.1 integer based) and want to submit Shailaja> the same to "WG" for review. [...] Shailaja> The question that I have is, do we submit such a draft in Shailaja> this WG (Disman) or Rmonmib WG ?. At the end of this mail I Shailaja> have appended a introduction part of our draft. The normal way is to submit an individual draft first. People can then read it and after that, the WGs in question can decide whether this should become a working group work item. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From exim@www1.ietf.org Wed Jan 14 07:49:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15851 for ; Wed, 14 Jan 2004 07:49:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgkRk-0005Fa-DT for disman-archive@odin.ietf.org; Wed, 14 Jan 2004 07:48:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0ECmWWk020176 for disman-archive@odin.ietf.org; Wed, 14 Jan 2004 07:48:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgkRk-0005FL-9n for disman-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 07:48:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15769 for ; Wed, 14 Jan 2004 07:48:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgkRj-0001RI-00 for disman-web-archive@ietf.org; Wed, 14 Jan 2004 07:48:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgkNE-0001JZ-00 for disman-web-archive@ietf.org; Wed, 14 Jan 2004 07:43:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgkIr-00017a-00 for disman-web-archive@ietf.org; Wed, 14 Jan 2004 07:39:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgkIX-0004xZ-01; Wed, 14 Jan 2004 07:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgkHi-0004uj-3y for disman@optimus.ietf.org; Wed, 14 Jan 2004 07:38:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15431 for ; Wed, 14 Jan 2004 07:38:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgkHX-00016L-00 for disman@ietf.org; Wed, 14 Jan 2004 07:37:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgkCd-0000vY-00 for disman@ietf.org; Wed, 14 Jan 2004 07:32:55 -0500 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by ietf-mx with esmtp (Exim 4.12) id 1Agk74-0000lG-00 for disman@ietf.org; Wed, 14 Jan 2004 07:27:10 -0500 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0ECQfIV024672 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 14 Jan 2004 13:26:41 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0ECQfCw024365; Wed, 14 Jan 2004 13:26:41 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) id i0ECQfRM024362; Wed, 14 Jan 2004 13:26:41 +0100 Message-Id: <200401141226.i0ECQfRM024362@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: yshailaja@novell.com CC: disman@ietf.org, HeKumar@novell.com, RShekar@novell.com, YHemanth@novell.com In-reply-to: (yshailaja@novell.com) Subject: Re: [Disman] Regarding the draft submission on the Object definition for the history collection References: X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Jan 2004 13:26:41 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 >>>>> Shailaja Yadawad writes: Shailaja> We have prepared a draft on object definition for history Shailaja> collection of Data( ASN.1 integer based) and want to submit Shailaja> the same to "WG" for review. [...] Shailaja> The question that I have is, do we submit such a draft in Shailaja> this WG (Disman) or Rmonmib WG ?. At the end of this mail I Shailaja> have appended a introduction part of our draft. The normal way is to submit an individual draft first. People can then read it and after that, the WGs in question can decide whether this should become a working group work item. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From disman-admin@ietf.org Mon Jan 19 15:07:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05495 for ; Mon, 19 Jan 2004 15:07:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiffo-0004KZ-Pv; Mon, 19 Jan 2004 15:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aifez-0003qf-8n for disman@optimus.ietf.org; Mon, 19 Jan 2004 15:06:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05297 for ; Mon, 19 Jan 2004 15:06:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aifer-0001H0-00 for disman@ietf.org; Mon, 19 Jan 2004 15:06:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aifdr-00019u-00 for disman@ietf.org; Mon, 19 Jan 2004 15:04:59 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Aifd9-000131-00 for disman@ietf.org; Mon, 19 Jan 2004 15:04:15 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0JK3hF20610 for ; Mon, 19 Jan 2004 15:03:43 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Jan 2004 15:03:43 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409DBD681@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Disman] Propose Resolution to iesg-1 and iesg-5 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Jan 2004 15:03:43 -0500 Hi The following is the proposed resolution to the final two issues raised as a result of the IESG reviews. I'd like to get the update to the document out within the next day or two, so please provide any objections to the resolutions as soon as possible. Note that both of these issues were around allocation of probable cause enumerations. See my email from January 13th for more information. ----- The following is the proposed resolution to IESG-1 and IESG-5 In the description for IanaItuProbableCause, replace the description "ITU probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAItuProbableCause values. Values of IANAItuProbableCause less than 1024 are reserved for causes that correspond to ITU probable cause. IANAItuProbableCause of 0 is reserved for special purposes and therefore cannot be assigned. See http://www.iana.org" With " ITU-T probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure syntactic uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAItuProbableCause values. IANAItuProbableCause of 0 is reserved for special purposes and MUST NOT be assigned. Values of IANAItuProbableCause in the range 1 to 1023 are reserved for causes that correspond to ITU-T probable cause. IANA will align causes with enumeration values within this range only as a result of requests received from the ITU-T via formal liaison statements. All other requests for new causes will be handled on a first-come, first served basis and will be assigned enumeration values starting with 1025. Request should come in the form of well-formed SMI for enumeration names that are unique and sufficiently descriptive. While some effort should be taken to ensure that new probable causes do not conceptually duplicate existing probable causes it is acknowledges that the existence of conceptual duplicates in the starting probable cause list is an acknowledged industry reality. See http://www.iana.org " Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From exim@www1.ietf.org Mon Jan 19 15:09:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05636 for ; Mon, 19 Jan 2004 15:09:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aifhb-0005bv-9d for disman-archive@odin.ietf.org; Mon, 19 Jan 2004 15:08:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JK8pKM021561 for disman-archive@odin.ietf.org; Mon, 19 Jan 2004 15:08:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aifhb-0005bb-56 for disman-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 15:08:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05585 for ; Mon, 19 Jan 2004 15:08:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AifhY-0001YT-00 for disman-web-archive@ietf.org; Mon, 19 Jan 2004 15:08:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aifgd-0001Uo-00 for disman-web-archive@ietf.org; Mon, 19 Jan 2004 15:07:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aiffs-0001Pc-00 for disman-web-archive@ietf.org; Mon, 19 Jan 2004 15:07:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiffo-0004KZ-Pv; Mon, 19 Jan 2004 15:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aifez-0003qf-8n for disman@optimus.ietf.org; Mon, 19 Jan 2004 15:06:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05297 for ; Mon, 19 Jan 2004 15:06:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aifer-0001H0-00 for disman@ietf.org; Mon, 19 Jan 2004 15:06:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aifdr-00019u-00 for disman@ietf.org; Mon, 19 Jan 2004 15:04:59 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Aifd9-000131-00 for disman@ietf.org; Mon, 19 Jan 2004 15:04:15 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0JK3hF20610 for ; Mon, 19 Jan 2004 15:03:43 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Jan 2004 15:03:43 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409DBD681@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Disman] Propose Resolution to iesg-1 and iesg-5 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Jan 2004 15:03:43 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi The following is the proposed resolution to the final two issues raised as a result of the IESG reviews. I'd like to get the update to the document out within the next day or two, so please provide any objections to the resolutions as soon as possible. Note that both of these issues were around allocation of probable cause enumerations. See my email from January 13th for more information. ----- The following is the proposed resolution to IESG-1 and IESG-5 In the description for IanaItuProbableCause, replace the description "ITU probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAItuProbableCause values. Values of IANAItuProbableCause less than 1024 are reserved for causes that correspond to ITU probable cause. IANAItuProbableCause of 0 is reserved for special purposes and therefore cannot be assigned. See http://www.iana.org" With " ITU-T probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure syntactic uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAItuProbableCause values. IANAItuProbableCause of 0 is reserved for special purposes and MUST NOT be assigned. Values of IANAItuProbableCause in the range 1 to 1023 are reserved for causes that correspond to ITU-T probable cause. IANA will align causes with enumeration values within this range only as a result of requests received from the ITU-T via formal liaison statements. All other requests for new causes will be handled on a first-come, first served basis and will be assigned enumeration values starting with 1025. Request should come in the form of well-formed SMI for enumeration names that are unique and sufficiently descriptive. While some effort should be taken to ensure that new probable causes do not conceptually duplicate existing probable causes it is acknowledges that the existence of conceptual duplicates in the starting probable cause list is an acknowledged industry reality. See http://www.iana.org " Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From disman-admin@ietf.org Tue Jan 20 05:58:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24277 for ; Tue, 20 Jan 2004 05:58:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aita4-0004m0-Fy; Tue, 20 Jan 2004 05:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AitZR-0004fh-87 for disman@optimus.ietf.org; Tue, 20 Jan 2004 05:57:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24242 for ; Tue, 20 Jan 2004 05:57:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AitZN-0007ag-00 for disman@ietf.org; Tue, 20 Jan 2004 05:57:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AitYe-0007Y5-00 for disman@ietf.org; Tue, 20 Jan 2004 05:56:33 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AitXu-0007QH-00 for disman@ietf.org; Tue, 20 Jan 2004 05:55:46 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0KAtFZ11302 for ; Tue, 20 Jan 2004 04:55:15 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 20 Jan 2004 11:09:26 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550362BA3D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Sharon Chisholm , disman@ietf.org Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Jan 2004 11:09:25 +0100 Inline > Hi > > The following is the proposed resolution to the final two issues raised as a > result of the IESG reviews. I'd like to get the update to the document out > within the next day or two, so please provide any objections to the > resolutions as soon as possible. > > Note that both of these issues were around allocation of probable cause > enumerations. See my email from January 13th for more information. > > ----- > > The following is the proposed resolution to IESG-1 and IESG-5 > > In the description for IanaItuProbableCause, replace the description > > "ITU probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure uniqueness. Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers, including > various SNMP-related numbers, and specifically, new > IANAItuProbableCause values. Values of > IANAItuProbableCause less than 1024 are reserved for causes > that correspond to ITU probable cause. IANAItuProbableCause > of 0 is reserved for special purposes and therefore cannot > be assigned. See http://www.iana.org" > > With > > " ITU-T probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure syntactic uniqueness. Probable > cause value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers, including > various SNMP-related numbers, and specifically, new why this extra 2 lines above. It seems irrelevant, but then it possibly does not hurt either. > IANAItuProbableCause values. IANAItuProbableCause > of 0 is reserved for special purposes and MUST NOT > be assigned. > > Values of IANAItuProbableCause in the range 1 to 1023 are reserved > for causes that correspond to ITU-T probable cause. IANA will align > causes with enumeration values within this range only as a result > of requests received from the ITU-T via formal liaison statements. > Not sure that formal Liaison statements is a good idea. ITU-T does send such statements to IETF, but requests should go directly to IANA. Normal way to request values is to send an email to iana@iana.org. I guess what we need to define is a way how IANA can make sure that the request comes from a valid/authoritative ITU-T SG ? > All other requests for new causes will be handled on a first-come, > first served basis and will be assigned enumeration values starting > with 1025. Request should come in the form of well-formed SMI for > enumeration names that are unique and sufficiently descriptive. > I wonder: - The MODULE-IDENTITY DESCRIPTION clause states that this TC is to represent ITU-T Probably Causes. Yet we have only 1024 numbers for them and some 2 billion for random assignment. Does that sound right? - Do we assume that iana understands the "well-formed SMI rules"?? Would be good to point to the RFC and section number that explains it. > While some effort should be taken to ensure that new probable causes > do not conceptually duplicate existing probable causes it is How is IANA to evaluate? > acknowledges that the existence of conceptual duplicates in the s/acknowledges/acknowledged/ > starting probable cause list is an acknowledged industry reality. > s/acknowledged// we have that in the previous line already Now... how many requests do we really suspect to arrive? Would it make sense to make it "expert review, expert to be appointed by OPS ADs or by IESG" ? ANd can we make Sharon and Dan the experts to start with? > > See http://www.iana.org > > " > Bert > Sharon Chisholm From exim@www1.ietf.org Tue Jan 20 05:59:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24306 for ; Tue, 20 Jan 2004 05:59:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AitbJ-0004r8-Ed for disman-archive@odin.ietf.org; Tue, 20 Jan 2004 05:59:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KAxHbV018662 for disman-archive@odin.ietf.org; Tue, 20 Jan 2004 05:59:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AitbJ-0004qv-7C for disman-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 05:59:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24303 for ; Tue, 20 Jan 2004 05:59:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AitbF-0007gC-00 for disman-web-archive@ietf.org; Tue, 20 Jan 2004 05:59:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AitaN-0007eF-00 for disman-web-archive@ietf.org; Tue, 20 Jan 2004 05:58:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aita6-0007bg-00 for disman-web-archive@ietf.org; Tue, 20 Jan 2004 05:58:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aita4-0004m0-Fy; Tue, 20 Jan 2004 05:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AitZR-0004fh-87 for disman@optimus.ietf.org; Tue, 20 Jan 2004 05:57:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24242 for ; Tue, 20 Jan 2004 05:57:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AitZN-0007ag-00 for disman@ietf.org; Tue, 20 Jan 2004 05:57:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AitYe-0007Y5-00 for disman@ietf.org; Tue, 20 Jan 2004 05:56:33 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AitXu-0007QH-00 for disman@ietf.org; Tue, 20 Jan 2004 05:55:46 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0KAtFZ11302 for ; Tue, 20 Jan 2004 04:55:15 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 20 Jan 2004 11:09:26 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550362BA3D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Sharon Chisholm , disman@ietf.org Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Jan 2004 11:09:25 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Inline > Hi > > The following is the proposed resolution to the final two issues raised as a > result of the IESG reviews. I'd like to get the update to the document out > within the next day or two, so please provide any objections to the > resolutions as soon as possible. > > Note that both of these issues were around allocation of probable cause > enumerations. See my email from January 13th for more information. > > ----- > > The following is the proposed resolution to IESG-1 and IESG-5 > > In the description for IanaItuProbableCause, replace the description > > "ITU probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure uniqueness. Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers, including > various SNMP-related numbers, and specifically, new > IANAItuProbableCause values. Values of > IANAItuProbableCause less than 1024 are reserved for causes > that correspond to ITU probable cause. IANAItuProbableCause > of 0 is reserved for special purposes and therefore cannot > be assigned. See http://www.iana.org" > > With > > " ITU-T probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure syntactic uniqueness. Probable > cause value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers, including > various SNMP-related numbers, and specifically, new why this extra 2 lines above. It seems irrelevant, but then it possibly does not hurt either. > IANAItuProbableCause values. IANAItuProbableCause > of 0 is reserved for special purposes and MUST NOT > be assigned. > > Values of IANAItuProbableCause in the range 1 to 1023 are reserved > for causes that correspond to ITU-T probable cause. IANA will align > causes with enumeration values within this range only as a result > of requests received from the ITU-T via formal liaison statements. > Not sure that formal Liaison statements is a good idea. ITU-T does send such statements to IETF, but requests should go directly to IANA. Normal way to request values is to send an email to iana@iana.org. I guess what we need to define is a way how IANA can make sure that the request comes from a valid/authoritative ITU-T SG ? > All other requests for new causes will be handled on a first-come, > first served basis and will be assigned enumeration values starting > with 1025. Request should come in the form of well-formed SMI for > enumeration names that are unique and sufficiently descriptive. > I wonder: - The MODULE-IDENTITY DESCRIPTION clause states that this TC is to represent ITU-T Probably Causes. Yet we have only 1024 numbers for them and some 2 billion for random assignment. Does that sound right? - Do we assume that iana understands the "well-formed SMI rules"?? Would be good to point to the RFC and section number that explains it. > While some effort should be taken to ensure that new probable causes > do not conceptually duplicate existing probable causes it is How is IANA to evaluate? > acknowledges that the existence of conceptual duplicates in the s/acknowledges/acknowledged/ > starting probable cause list is an acknowledged industry reality. > s/acknowledged// we have that in the previous line already Now... how many requests do we really suspect to arrive? Would it make sense to make it "expert review, expert to be appointed by OPS ADs or by IESG" ? ANd can we make Sharon and Dan the experts to start with? > > See http://www.iana.org > > " > Bert > Sharon Chisholm From disman-admin@ietf.org Tue Jan 20 09:26:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00970 for ; Tue, 20 Jan 2004 09:26:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiwpP-00084A-A3; Tue, 20 Jan 2004 09:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiwoq-00082z-TK for disman@optimus.ietf.org; Tue, 20 Jan 2004 09:25:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00915 for ; Tue, 20 Jan 2004 09:25:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiwoo-0002a3-00 for disman@ietf.org; Tue, 20 Jan 2004 09:25:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiwns-0002X6-00 for disman@ietf.org; Tue, 20 Jan 2004 09:24:29 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AiwnP-0002TK-00 for disman@ietf.org; Tue, 20 Jan 2004 09:23:59 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0KENRG28116 for ; Tue, 20 Jan 2004 09:23:28 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Jan 2004 09:23:28 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409DBDA87@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Jan 2004 09:23:26 -0500 -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] why this extra 2 lines above. It seems irrelevant, but then it possibly does not hurt either. I think I got an extra line wrap that I wasn't expecting. Not sure that formal Liaison statements is a good idea. ITU-T does send such statements to IETF, but requests should go directly to IANA. Normal way to request values is to send an email to iana@iana.org. I guess what we need to define is a way how IANA can make sure that the request comes from a valid/authoritative ITU-T SG ? Well, an liaison is more or less an email. Could we then say that the email would be received from the ITU-T. If the ITU-T chose to send it as a liaison, then it will have formal ITU-T header information which indicates its source. We could simply say the following: " IANA will align causes with enumeration values within this range only as a result of formal requests received from the ITU-T." I wonder: - The MODULE-IDENTITY DESCRIPTION clause states that this TC is to represent ITU-T Probably Causes. Yet we have only 1024 numbers for them and some 2 billion for random assignment. Does that sound right? Yes, but if ITU-T SG 4 is happy with being allocated this range, isn't that enough? - Do we assume that iana understands the "well-formed SMI rules"?? Would be good to point to the RFC and section number that explains it. Excellent suggestion. > While some effort should be taken to ensure that new probable causes > do not conceptually duplicate existing probable causes it > is How is IANA to evaluate? It is a difficult things for anyone to evaluate given the nature of probable cause. We could push the responsibility onto the person applying or have it quickly reviewed as you suggest below. > acknowledges that the existence of conceptual duplicates in > the s/acknowledges/acknowledged/ > starting probable cause list is an acknowledged industry > reality. > s/acknowledged// we have that in the previous line already Yes, I only noticed these after I sent the email. Now... how many requests do we really suspect to arrive? Would it make sense to make it "expert review, expert to be appointed by OPS ADs or by IESG" ? ANd can we make Sharon and Dan the experts to start with? It's hard to predict how may we would get. Would it be possible to start with having expert review and if we determined it wasn't really adding value or a good use of time we drop it later on? Sharon From exim@www1.ietf.org Tue Jan 20 09:27:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01010 for ; Tue, 20 Jan 2004 09:27:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiwqg-00087e-BN for disman-archive@odin.ietf.org; Tue, 20 Jan 2004 09:27:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KERMu9031216 for disman-archive@odin.ietf.org; Tue, 20 Jan 2004 09:27:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiwqg-00087P-89 for disman-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 09:27:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01000 for ; Tue, 20 Jan 2004 09:27:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiwqe-0002ei-00 for disman-web-archive@ietf.org; Tue, 20 Jan 2004 09:27:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiwpm-0002d3-00 for disman-web-archive@ietf.org; Tue, 20 Jan 2004 09:26:27 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AiwpS-0002aj-00 for disman-web-archive@ietf.org; Tue, 20 Jan 2004 09:26:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiwpP-00084A-A3; Tue, 20 Jan 2004 09:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiwoq-00082z-TK for disman@optimus.ietf.org; Tue, 20 Jan 2004 09:25:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00915 for ; Tue, 20 Jan 2004 09:25:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiwoo-0002a3-00 for disman@ietf.org; Tue, 20 Jan 2004 09:25:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiwns-0002X6-00 for disman@ietf.org; Tue, 20 Jan 2004 09:24:29 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AiwnP-0002TK-00 for disman@ietf.org; Tue, 20 Jan 2004 09:23:59 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0KENRG28116 for ; Tue, 20 Jan 2004 09:23:28 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Jan 2004 09:23:28 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409DBDA87@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Jan 2004 09:23:26 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] why this extra 2 lines above. It seems irrelevant, but then it possibly does not hurt either. I think I got an extra line wrap that I wasn't expecting. Not sure that formal Liaison statements is a good idea. ITU-T does send such statements to IETF, but requests should go directly to IANA. Normal way to request values is to send an email to iana@iana.org. I guess what we need to define is a way how IANA can make sure that the request comes from a valid/authoritative ITU-T SG ? Well, an liaison is more or less an email. Could we then say that the email would be received from the ITU-T. If the ITU-T chose to send it as a liaison, then it will have formal ITU-T header information which indicates its source. We could simply say the following: " IANA will align causes with enumeration values within this range only as a result of formal requests received from the ITU-T." I wonder: - The MODULE-IDENTITY DESCRIPTION clause states that this TC is to represent ITU-T Probably Causes. Yet we have only 1024 numbers for them and some 2 billion for random assignment. Does that sound right? Yes, but if ITU-T SG 4 is happy with being allocated this range, isn't that enough? - Do we assume that iana understands the "well-formed SMI rules"?? Would be good to point to the RFC and section number that explains it. Excellent suggestion. > While some effort should be taken to ensure that new probable causes > do not conceptually duplicate existing probable causes it > is How is IANA to evaluate? It is a difficult things for anyone to evaluate given the nature of probable cause. We could push the responsibility onto the person applying or have it quickly reviewed as you suggest below. > acknowledges that the existence of conceptual duplicates in > the s/acknowledges/acknowledged/ > starting probable cause list is an acknowledged industry > reality. > s/acknowledged// we have that in the previous line already Yes, I only noticed these after I sent the email. Now... how many requests do we really suspect to arrive? Would it make sense to make it "expert review, expert to be appointed by OPS ADs or by IESG" ? ANd can we make Sharon and Dan the experts to start with? It's hard to predict how may we would get. Would it be possible to start with having expert review and if we determined it wasn't really adding value or a good use of time we drop it later on? Sharon From disman-admin@ietf.org Tue Jan 20 11:29:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09859 for ; Tue, 20 Jan 2004 11:29:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiykP-0006Pg-L5; Tue, 20 Jan 2004 11:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiyjt-0006PI-K1 for disman@optimus.ietf.org; Tue, 20 Jan 2004 11:28:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09761 for ; Tue, 20 Jan 2004 11:28:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiyjs-0003Gr-00 for disman@ietf.org; Tue, 20 Jan 2004 11:28:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiyiz-0003EU-00 for disman@ietf.org; Tue, 20 Jan 2004 11:27:34 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Aiyih-0003BS-00 for disman@ietf.org; Tue, 20 Jan 2004 11:27:16 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0KGQgZ09641 for ; Tue, 20 Jan 2004 10:26:42 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 20 Jan 2004 16:41:03 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550362BB7D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Sharon Chisholm , disman@ietf.org Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Jan 2004 16:41:02 +0100 Inline > > why this extra 2 lines above. It seems irrelevant, but then > it possibly does not hurt either. > > > I think I got an extra line wrap that I wasn't expecting. > I did not mean the blank lines. But the text The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAItuProbableCause values. would it not be better to just say: The Internet Assigned Number Authority (IANA) is responsible for the assignment of new IANAItuProbableCause values. Cause the piece I removed is irrelevant for this MIB module. > > > Not sure that formal Liaison statements is a good idea. > ITU-T does send such statements to IETF, but requests should > go directly to > IANA. Normal way to request values is to send an email to > iana@iana.org. I > guess what we need to define is a way how IANA can make sure that the > request comes from a valid/authoritative ITU-T SG ? > > > Well, an liaison is more or less an email. Could we then say that the email > would be received from the ITU-T. If the ITU-T chose to send it as a > liaison, then it will have formal ITU-T header information > which indicates its source. > But IANA and ITU do not have a "liaison agreement". And if ITU sends it to the IETF Liaison person (Scott Bradner), then that is just an additional in-between step that seems to serve no purpose to me. > We could simply say the following: > > " > IANA will align causes with enumeration values within this > range only as a result of formal requests received from the ITU-T." > I bet that IANA is going to wonder "how can we identify/verify that a request is a formal request from ITU". > > > I wonder: > - The MODULE-IDENTITY DESCRIPTION clause states that this TC > is to represent > ITU-T Probably Causes. Yet we have only 1024 numbers for > them and some > 2 billion for random assignment. Does that sound right? > > > Yes, but if ITU-T SG 4 is happy with being allocated this > range, isn't that enough? > Yes, it is enuf for ITU, but give the numbers, it seems weird to claim that it is an ITU thing if by far the largest piece fo the namespace is for FCFS (i.e. anybody can come up with their own what-ever). > > - Do we assume that iana understands the "well-formed SMI rules"?? > Would be good to point to the RFC and section number that > explains it. > > > Excellent suggestion. > > > > While some effort should be taken to ensure that > new probable > causes > > do not conceptually duplicate existing probable > causes it > > is > > How is IANA to evaluate? > > > It is a difficult things for anyone to evaluate given the > nature of probable > cause. We could push the responsibility onto the person > applying or have it > quickly reviewed as you suggest below. > > > > acknowledges that the existence of conceptual > duplicates in > > the > > s/acknowledges/acknowledged/ > > > starting probable cause list is an acknowledged industry > > reality. > > > s/acknowledged// > we have that in the previous line already > > > Yes, I only noticed these after I sent the email. > > > Now... how many requests do we really suspect to arrive? > Would it make sense to make it "expert review, expert to be > appointed by OPS > ADs or by IESG" ? ANd can we make Sharon and Dan the experts > to start with? > > > It's hard to predict how may we would get. Would it be possible to start > with having expert review and if we determined it wasn't really adding value > or a good use of time we drop it later on? > I think so. I think that maybe the best is to make it so that IANA can assign (based on the guidelines/rules we write up in the DESCRIPTION clause" with an added expert review (as appointed by OPS ADs) for IANA to consult. Bert > Sharon > From exim@www1.ietf.org Tue Jan 20 11:31:01 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10036 for ; Tue, 20 Jan 2004 11:31:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiylt-0006bu-FH for disman-archive@odin.ietf.org; Tue, 20 Jan 2004 11:30:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KGUXF3025409 for disman-archive@odin.ietf.org; Tue, 20 Jan 2004 11:30:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiylt-0006bk-CF for disman-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 11:30:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09938 for ; Tue, 20 Jan 2004 11:30:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiylr-0003QG-00 for disman-web-archive@ietf.org; Tue, 20 Jan 2004 11:30:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiyl4-0003NB-00 for disman-web-archive@ietf.org; Tue, 20 Jan 2004 11:29:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AiykW-0003Iz-00 for disman-web-archive@ietf.org; Tue, 20 Jan 2004 11:29:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiykP-0006Pg-L5; Tue, 20 Jan 2004 11:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiyjt-0006PI-K1 for disman@optimus.ietf.org; Tue, 20 Jan 2004 11:28:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09761 for ; Tue, 20 Jan 2004 11:28:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiyjs-0003Gr-00 for disman@ietf.org; Tue, 20 Jan 2004 11:28:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiyiz-0003EU-00 for disman@ietf.org; Tue, 20 Jan 2004 11:27:34 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Aiyih-0003BS-00 for disman@ietf.org; Tue, 20 Jan 2004 11:27:16 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0KGQgZ09641 for ; Tue, 20 Jan 2004 10:26:42 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 20 Jan 2004 16:41:03 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550362BB7D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Sharon Chisholm , disman@ietf.org Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Jan 2004 16:41:02 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Inline > > why this extra 2 lines above. It seems irrelevant, but then > it possibly does not hurt either. > > > I think I got an extra line wrap that I wasn't expecting. > I did not mean the blank lines. But the text The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAItuProbableCause values. would it not be better to just say: The Internet Assigned Number Authority (IANA) is responsible for the assignment of new IANAItuProbableCause values. Cause the piece I removed is irrelevant for this MIB module. > > > Not sure that formal Liaison statements is a good idea. > ITU-T does send such statements to IETF, but requests should > go directly to > IANA. Normal way to request values is to send an email to > iana@iana.org. I > guess what we need to define is a way how IANA can make sure that the > request comes from a valid/authoritative ITU-T SG ? > > > Well, an liaison is more or less an email. Could we then say that the email > would be received from the ITU-T. If the ITU-T chose to send it as a > liaison, then it will have formal ITU-T header information > which indicates its source. > But IANA and ITU do not have a "liaison agreement". And if ITU sends it to the IETF Liaison person (Scott Bradner), then that is just an additional in-between step that seems to serve no purpose to me. > We could simply say the following: > > " > IANA will align causes with enumeration values within this > range only as a result of formal requests received from the ITU-T." > I bet that IANA is going to wonder "how can we identify/verify that a request is a formal request from ITU". > > > I wonder: > - The MODULE-IDENTITY DESCRIPTION clause states that this TC > is to represent > ITU-T Probably Causes. Yet we have only 1024 numbers for > them and some > 2 billion for random assignment. Does that sound right? > > > Yes, but if ITU-T SG 4 is happy with being allocated this > range, isn't that enough? > Yes, it is enuf for ITU, but give the numbers, it seems weird to claim that it is an ITU thing if by far the largest piece fo the namespace is for FCFS (i.e. anybody can come up with their own what-ever). > > - Do we assume that iana understands the "well-formed SMI rules"?? > Would be good to point to the RFC and section number that > explains it. > > > Excellent suggestion. > > > > While some effort should be taken to ensure that > new probable > causes > > do not conceptually duplicate existing probable > causes it > > is > > How is IANA to evaluate? > > > It is a difficult things for anyone to evaluate given the > nature of probable > cause. We could push the responsibility onto the person > applying or have it > quickly reviewed as you suggest below. > > > > acknowledges that the existence of conceptual > duplicates in > > the > > s/acknowledges/acknowledged/ > > > starting probable cause list is an acknowledged industry > > reality. > > > s/acknowledged// > we have that in the previous line already > > > Yes, I only noticed these after I sent the email. > > > Now... how many requests do we really suspect to arrive? > Would it make sense to make it "expert review, expert to be > appointed by OPS > ADs or by IESG" ? ANd can we make Sharon and Dan the experts > to start with? > > > It's hard to predict how may we would get. Would it be possible to start > with having expert review and if we determined it wasn't really adding value > or a good use of time we drop it later on? > I think so. I think that maybe the best is to make it so that IANA can assign (based on the guidelines/rules we write up in the DESCRIPTION clause" with an added expert review (as appointed by OPS ADs) for IANA to consult. Bert > Sharon > From disman-admin@ietf.org Tue Jan 20 16:48:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26925 for ; Tue, 20 Jan 2004 16:48:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj3j6-000434-Ju; Tue, 20 Jan 2004 16:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj3ik-0003wO-Gs for disman@optimus.ietf.org; Tue, 20 Jan 2004 16:47:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26894 for ; Tue, 20 Jan 2004 16:47:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj3ii-0007Nq-00 for disman@ietf.org; Tue, 20 Jan 2004 16:47:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj3hn-0007Kn-00 for disman@ietf.org; Tue, 20 Jan 2004 16:46:39 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1Aj3gs-0007H1-00 for disman@ietf.org; Tue, 20 Jan 2004 16:45:42 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0KLjBP09104 for ; Tue, 20 Jan 2004 16:45:11 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Jan 2004 16:45:10 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409E2B43A@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 2) Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Jan 2004 16:45:09 -0500 Hi Here is an updated proposed resolution based on Bert's comments ----- The following is the proposed resolution to IESG-1 and IESG-5 In the description for IanaItuProbableCause, replace the description "ITU probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAItuProbableCause values. Values of IANAItuProbableCause less than 1024 are reserved for causes that correspond to ITU probable cause. IANAItuProbableCause of 0 is reserved for special purposes and therefore cannot be assigned. See http://www.iana.org" With " ITU-T probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure syntactic uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers. IANAItuProbableCause of 0 is reserved for special purposes and MUST NOT be assigned. Values of IANAItuProbableCause in the range 1 to 1023 are reserved for causes that correspond to ITU-T probable cause. All other requests for new causes will be handled on a first-come, first served basis and will be assigned enumeration values starting with 1025. Request should come in the form of well-formed SMI [RFC2578] for enumeration names that are unique and sufficiently descriptive. While some effort will be taken to ensure that new probable causes do not conceptually duplicate existing probable causes it is acknowledged that the existence of conceptual duplicates in the starting probable cause list is an known industry reality. To aid IANA in the administration of probable cause names and values, the Management Area Director will appoint an expert to help review requests. See http://www.iana.org " Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From exim@www1.ietf.org Tue Jan 20 16:50:09 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27034 for ; Tue, 20 Jan 2004 16:50:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj3kj-00049R-T1 for disman-archive@odin.ietf.org; Tue, 20 Jan 2004 16:49:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KLnfbP015956 for disman-archive@odin.ietf.org; Tue, 20 Jan 2004 16:49:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj3kj-00049H-Oi for disman-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 16:49:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27020 for ; Tue, 20 Jan 2004 16:49:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj3kh-0007Wm-00 for disman-web-archive@ietf.org; Tue, 20 Jan 2004 16:49:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj3jr-0007Th-00 for disman-web-archive@ietf.org; Tue, 20 Jan 2004 16:48:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aj3jC-0007Q3-00 for disman-web-archive@ietf.org; Tue, 20 Jan 2004 16:48:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj3j6-000434-Ju; Tue, 20 Jan 2004 16:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj3ik-0003wO-Gs for disman@optimus.ietf.org; Tue, 20 Jan 2004 16:47:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26894 for ; Tue, 20 Jan 2004 16:47:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj3ii-0007Nq-00 for disman@ietf.org; Tue, 20 Jan 2004 16:47:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj3hn-0007Kn-00 for disman@ietf.org; Tue, 20 Jan 2004 16:46:39 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1Aj3gs-0007H1-00 for disman@ietf.org; Tue, 20 Jan 2004 16:45:42 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0KLjBP09104 for ; Tue, 20 Jan 2004 16:45:11 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Jan 2004 16:45:10 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409E2B43A@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 2) Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Jan 2004 16:45:09 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Here is an updated proposed resolution based on Bert's comments ----- The following is the proposed resolution to IESG-1 and IESG-5 In the description for IanaItuProbableCause, replace the description "ITU probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAItuProbableCause values. Values of IANAItuProbableCause less than 1024 are reserved for causes that correspond to ITU probable cause. IANAItuProbableCause of 0 is reserved for special purposes and therefore cannot be assigned. See http://www.iana.org" With " ITU-T probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure syntactic uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers. IANAItuProbableCause of 0 is reserved for special purposes and MUST NOT be assigned. Values of IANAItuProbableCause in the range 1 to 1023 are reserved for causes that correspond to ITU-T probable cause. All other requests for new causes will be handled on a first-come, first served basis and will be assigned enumeration values starting with 1025. Request should come in the form of well-formed SMI [RFC2578] for enumeration names that are unique and sufficiently descriptive. While some effort will be taken to ensure that new probable causes do not conceptually duplicate existing probable causes it is acknowledged that the existence of conceptual duplicates in the starting probable cause list is an known industry reality. To aid IANA in the administration of probable cause names and values, the Management Area Director will appoint an expert to help review requests. See http://www.iana.org " Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From disman-admin@ietf.org Wed Jan 21 10:39:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26573 for ; Wed, 21 Jan 2004 10:39:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKRY-0007RL-JS; Wed, 21 Jan 2004 10:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKQn-0007Mr-7m for disman@optimus.ietf.org; Wed, 21 Jan 2004 10:38:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26510 for ; Wed, 21 Jan 2004 10:38:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjKQk-0003rO-00 for disman@ietf.org; Wed, 21 Jan 2004 10:38:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjKPn-0003pt-00 for disman@ietf.org; Wed, 21 Jan 2004 10:37:12 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AjKP4-0003mA-00 for disman@ietf.org; Wed, 21 Jan 2004 10:36:26 -0500 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0LFZnkA003909 for ; Wed, 21 Jan 2004 16:35:49 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 80350FBC21 for ; Wed, 21 Jan 2004 16:35:48 +0100 (CET) From: Juergen Quittek To: disman@ietf.org Message-ID: <2147483647.1074702954@[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-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Disman] ping-mib-1 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 16:35:54 +0100 Content-Transfer-Encoding: 7bit Dear all, I'm editing a new version of the remote operations MIBs. Besides a number of editorial issues I found three issues that I want to discuss on the list, one for each MIB module. Here is the first one. In the PING MIB there is a contradiction in the definition of pingCtlTrapGeneration OBJECT-TYPE SYNTAX BITS { probeFailure(0), testFailure(1), testCompletion(2) } MAX-ACCESS read-create STATUS current 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. The object pingCtlTrapProbeFailureFilter can be used to specify the number of successive probe failures that are required before a pingProbeFailed notification can be generated. testFailure(1) - Generate a pingTestFailed notification. In this instance the object pingCtlTrapTestFailureFilter can be used to determine the number of probe failures that signal when a test fails. testCompletion(2) - Generate a pingTestCompleted notification. The value of this object defaults to zero, indicating that none of the above options have been selected." ::= { pingCtlEntry 13 } The last sentence of the DESCRIPTION clause refers to a default value for which none of the option is selected. Such a value is not defined. Also there is no DEFVAL clause. I see alternatives to fix this: 1. We can just remove the last sentence from the DESCRIPTION clause. Then we would not have a value for this object that allows to disable generation of Notification in all cases. 2. We can add a value none(4), add DEFVAL { none }, and replace "zero" by "none(4)" in the last sentence of the description clause. 3. We can leave the DESCRIPTION clause almost unchanged and renumber the values: SYNTAX BITS { none(0), probeFailure(1), testFailure(2), testCompletion(3) } Does anyone has a strong preference or another solution of this issue? 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.ccrle.nec.de From exim@www1.ietf.org Wed Jan 21 10:41:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26679 for ; Wed, 21 Jan 2004 10:41:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKTc-0007dV-NE for disman-archive@odin.ietf.org; Wed, 21 Jan 2004 10:41:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LFf8hS029349 for disman-archive@odin.ietf.org; Wed, 21 Jan 2004 10:41:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKTc-0007dI-I9 for disman-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 10:41:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26641 for ; Wed, 21 Jan 2004 10:41:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjKTa-0003xY-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 10:41:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjKSb-0003vP-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 10:40:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjKRf-0003tN-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 10:39:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKRY-0007RL-JS; Wed, 21 Jan 2004 10:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKQn-0007Mr-7m for disman@optimus.ietf.org; Wed, 21 Jan 2004 10:38:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26510 for ; Wed, 21 Jan 2004 10:38:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjKQk-0003rO-00 for disman@ietf.org; Wed, 21 Jan 2004 10:38:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjKPn-0003pt-00 for disman@ietf.org; Wed, 21 Jan 2004 10:37:12 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AjKP4-0003mA-00 for disman@ietf.org; Wed, 21 Jan 2004 10:36:26 -0500 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0LFZnkA003909 for ; Wed, 21 Jan 2004 16:35:49 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 80350FBC21 for ; Wed, 21 Jan 2004 16:35:48 +0100 (CET) From: Juergen Quittek To: disman@ietf.org Message-ID: <2147483647.1074702954@[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-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Disman] ping-mib-1 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 16:35:54 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, I'm editing a new version of the remote operations MIBs. Besides a number of editorial issues I found three issues that I want to discuss on the list, one for each MIB module. Here is the first one. In the PING MIB there is a contradiction in the definition of pingCtlTrapGeneration OBJECT-TYPE SYNTAX BITS { probeFailure(0), testFailure(1), testCompletion(2) } MAX-ACCESS read-create STATUS current 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. The object pingCtlTrapProbeFailureFilter can be used to specify the number of successive probe failures that are required before a pingProbeFailed notification can be generated. testFailure(1) - Generate a pingTestFailed notification. In this instance the object pingCtlTrapTestFailureFilter can be used to determine the number of probe failures that signal when a test fails. testCompletion(2) - Generate a pingTestCompleted notification. The value of this object defaults to zero, indicating that none of the above options have been selected." ::= { pingCtlEntry 13 } The last sentence of the DESCRIPTION clause refers to a default value for which none of the option is selected. Such a value is not defined. Also there is no DEFVAL clause. I see alternatives to fix this: 1. We can just remove the last sentence from the DESCRIPTION clause. Then we would not have a value for this object that allows to disable generation of Notification in all cases. 2. We can add a value none(4), add DEFVAL { none }, and replace "zero" by "none(4)" in the last sentence of the description clause. 3. We can leave the DESCRIPTION clause almost unchanged and renumber the values: SYNTAX BITS { none(0), probeFailure(1), testFailure(2), testCompletion(3) } Does anyone has a strong preference or another solution of this issue? 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.ccrle.nec.de From disman-admin@ietf.org Wed Jan 21 10:56:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27147 for ; Wed, 21 Jan 2004 10:56:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKi1-0000LS-Uk; Wed, 21 Jan 2004 10:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKhH-0000IR-Cf for disman@optimus.ietf.org; Wed, 21 Jan 2004 10:55:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27125 for ; Wed, 21 Jan 2004 10:55:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjKhE-0004ZH-00 for disman@ietf.org; Wed, 21 Jan 2004 10:55:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjKgG-0004X3-00 for disman@ietf.org; Wed, 21 Jan 2004 10:54:13 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AjKfe-0004TJ-00 for disman@ietf.org; Wed, 21 Jan 2004 10:53:34 -0500 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0LFr3kA006790 for ; Wed, 21 Jan 2004 16:53:03 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id CA28BFBEBB for ; Wed, 21 Jan 2004 16:53:02 +0100 (CET) From: Juergen Quittek To: disman@ietf.org Message-ID: <2147483647.1074703989@[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-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Disman] traceroute-mib-1 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 16:53:09 +0100 Content-Transfer-Encoding: 7bit Dear all, Here is an issue on the TRACEROUTE MIB: I want to clarify the DESCRIPTION clause of object traceRouteResultsLastGoodPath OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when the last complete path was determined." ::= { traceRouteResultsEntry 8 } Does anyone have an understanding of the term "complete path" that differs from the following? DESCRIPTION "The date and time when the last complete path was determined. A path is complete if the IP address of each hop along the path has been detected." 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 From exim@www1.ietf.org Wed Jan 21 10:57:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27176 for ; Wed, 21 Jan 2004 10:57:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKjC-0000SG-Rb for disman-archive@odin.ietf.org; Wed, 21 Jan 2004 10:57:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LFvEAe001747 for disman-archive@odin.ietf.org; Wed, 21 Jan 2004 10:57:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKjC-0000S6-NC for disman-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 10:57:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27172 for ; Wed, 21 Jan 2004 10:57:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjKjA-0004e3-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 10:57:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjKiH-0004cH-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 10:56:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjKi1-0004a3-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 10:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKi1-0000LS-Uk; Wed, 21 Jan 2004 10:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKhH-0000IR-Cf for disman@optimus.ietf.org; Wed, 21 Jan 2004 10:55:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27125 for ; Wed, 21 Jan 2004 10:55:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjKhE-0004ZH-00 for disman@ietf.org; Wed, 21 Jan 2004 10:55:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjKgG-0004X3-00 for disman@ietf.org; Wed, 21 Jan 2004 10:54:13 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AjKfe-0004TJ-00 for disman@ietf.org; Wed, 21 Jan 2004 10:53:34 -0500 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0LFr3kA006790 for ; Wed, 21 Jan 2004 16:53:03 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id CA28BFBEBB for ; Wed, 21 Jan 2004 16:53:02 +0100 (CET) From: Juergen Quittek To: disman@ietf.org Message-ID: <2147483647.1074703989@[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-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Disman] traceroute-mib-1 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 16:53:09 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, Here is an issue on the TRACEROUTE MIB: I want to clarify the DESCRIPTION clause of object traceRouteResultsLastGoodPath OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when the last complete path was determined." ::= { traceRouteResultsEntry 8 } Does anyone have an understanding of the term "complete path" that differs from the following? DESCRIPTION "The date and time when the last complete path was determined. A path is complete if the IP address of each hop along the path has been detected." 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 From disman-admin@ietf.org Wed Jan 21 11:05:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27481 for ; Wed, 21 Jan 2004 11:05:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKqk-0000sU-O5; Wed, 21 Jan 2004 11:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKq9-0000rV-35 for disman@optimus.ietf.org; Wed, 21 Jan 2004 11:04:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27423 for ; Wed, 21 Jan 2004 11:04:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjKq6-0004uz-00 for disman@ietf.org; Wed, 21 Jan 2004 11:04:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjKp4-0004sH-00 for disman@ietf.org; Wed, 21 Jan 2004 11:03:19 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AjKoq-0004pd-00 for disman@ietf.org; Wed, 21 Jan 2004 11:03:04 -0500 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0LG2XkA007944 for ; Wed, 21 Jan 2004 17:02:33 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 93FC6FBEC5 for ; Wed, 21 Jan 2004 17:02:32 +0100 (CET) From: Juergen Quittek To: disman@ietf.org Message-ID: <2147483647.1074704559@[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-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Disman] lookup-mib-1 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 17:02:39 +0100 Content-Transfer-Encoding: 7bit Dear all, Here is the LOOKUP MIB issue: Object lookupCtlOperStatus is defined as lookupCtlOperStatus OBJECT-TYPE SYNTAX INTEGER { notStarted(2), -- operation has not started completed(3) -- operation is done } MAX-ACCESS read-only STATUS current DESCRIPTION "Reflects the operational state of an lookupCtlEntry: enabled(1) - Operation is active. notStarted(2) - Operation has not been enabled. completed(3) - Operation has completed. An operation is automatically enabled(1) when its lookupCtlRowStatus object is transitioned to active(1) status. Until this occurs lookupCtlOperStatus MUST report a value of notStarted(2). After the lookup operation completes (success or failure) the value for lookupCtlOperStatus MUST be transitioned to completed(3)." ::= { lookupCtlEntry 5 } Obviously, value enabled(1) is missing in the SYNTAX clause. It needs to be added. I guess implementers of this MIB module did implement it anyway. My question is: Does adding this (obvious) value to the SYNTAX clause require the document to start again as proposed standard or can it progress with this change towards draft standard? 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.ccrle.nec.de From exim@www1.ietf.org Wed Jan 21 11:06:46 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27556 for ; Wed, 21 Jan 2004 11:06:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKs0-00010i-1I for disman-archive@odin.ietf.org; Wed, 21 Jan 2004 11:06:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LG6Kci003878 for disman-archive@odin.ietf.org; Wed, 21 Jan 2004 11:06:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKrz-00010T-US for disman-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 11:06:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27551 for ; Wed, 21 Jan 2004 11:06:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjKrx-00052W-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 11:06:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjKr6-000503-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 11:05:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjKqi-0004wi-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 11:05:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKqk-0000sU-O5; Wed, 21 Jan 2004 11:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKq9-0000rV-35 for disman@optimus.ietf.org; Wed, 21 Jan 2004 11:04:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27423 for ; Wed, 21 Jan 2004 11:04:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjKq6-0004uz-00 for disman@ietf.org; Wed, 21 Jan 2004 11:04:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjKp4-0004sH-00 for disman@ietf.org; Wed, 21 Jan 2004 11:03:19 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AjKoq-0004pd-00 for disman@ietf.org; Wed, 21 Jan 2004 11:03:04 -0500 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0LG2XkA007944 for ; Wed, 21 Jan 2004 17:02:33 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 93FC6FBEC5 for ; Wed, 21 Jan 2004 17:02:32 +0100 (CET) From: Juergen Quittek To: disman@ietf.org Message-ID: <2147483647.1074704559@[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-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Disman] lookup-mib-1 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 17:02:39 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, Here is the LOOKUP MIB issue: Object lookupCtlOperStatus is defined as lookupCtlOperStatus OBJECT-TYPE SYNTAX INTEGER { notStarted(2), -- operation has not started completed(3) -- operation is done } MAX-ACCESS read-only STATUS current DESCRIPTION "Reflects the operational state of an lookupCtlEntry: enabled(1) - Operation is active. notStarted(2) - Operation has not been enabled. completed(3) - Operation has completed. An operation is automatically enabled(1) when its lookupCtlRowStatus object is transitioned to active(1) status. Until this occurs lookupCtlOperStatus MUST report a value of notStarted(2). After the lookup operation completes (success or failure) the value for lookupCtlOperStatus MUST be transitioned to completed(3)." ::= { lookupCtlEntry 5 } Obviously, value enabled(1) is missing in the SYNTAX clause. It needs to be added. I guess implementers of this MIB module did implement it anyway. My question is: Does adding this (obvious) value to the SYNTAX clause require the document to start again as proposed standard or can it progress with this change towards draft standard? 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.ccrle.nec.de From disman-admin@ietf.org Wed Jan 21 11:36:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28873 for ; Wed, 21 Jan 2004 11:36:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLKi-0002i4-O1; Wed, 21 Jan 2004 11:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLJs-0002dH-RL for disman@optimus.ietf.org; Wed, 21 Jan 2004 11:35:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28812 for ; Wed, 21 Jan 2004 11:35:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjLJr-0006Mv-00 for disman@ietf.org; Wed, 21 Jan 2004 11:35:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjLIu-0006Je-00 for disman@ietf.org; Wed, 21 Jan 2004 11:34:09 -0500 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by ietf-mx with esmtp (Exim 4.12) id 1AjLHy-0006F9-00 for disman@ietf.org; Wed, 21 Jan 2004 11:33:11 -0500 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0LGX07R026418 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 21 Jan 2004 17:33:00 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0LGX0Cw001089; Wed, 21 Jan 2004 17:33:00 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) id i0LGX0QE001086; Wed, 21 Jan 2004 17:33:00 +0100 Message-Id: <200401211633.i0LGX0QE001086@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: quittek@ccrle.nec.de CC: disman@ietf.org In-reply-to: <2147483647.1074702954@[10.1.1.171]> (message from Juergen Quittek on Wed, 21 Jan 2004 16:35:54 +0100) Subject: Re: [Disman] ping-mib-1 References: <2147483647.1074702954@[10.1.1.171]> X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 17:33:00 +0100 >>>>> Juergen Quittek writes: Juergen> Dear all, Juergen> Here is the first one. In the PING MIB there is a Juergen> contradiction in the definition of Juergen> pingCtlTrapGeneration [...] Juergen> Does anyone has a strong preference or another solution of Juergen> this issue? I think the correct DEFAL to add is DEFVAL { {} } -- No bits set. and the text needs to be modified to talk about a bit string with no bits set or a zero-length bit string or whatever you prefer. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From exim@www1.ietf.org Wed Jan 21 11:37:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28942 for ; Wed, 21 Jan 2004 11:37:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLLs-0002ro-Fy for disman-archive@odin.ietf.org; Wed, 21 Jan 2004 11:37:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LGbCsf011005 for disman-archive@odin.ietf.org; Wed, 21 Jan 2004 11:37:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLLr-0002rH-Vh for disman-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 11:37:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28915 for ; Wed, 21 Jan 2004 11:37:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjLLq-0006SU-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 11:37:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjLKx-0006Qs-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 11:36:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjLKj-0006Ov-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 11:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLKi-0002i4-O1; Wed, 21 Jan 2004 11:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLJs-0002dH-RL for disman@optimus.ietf.org; Wed, 21 Jan 2004 11:35:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28812 for ; Wed, 21 Jan 2004 11:35:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjLJr-0006Mv-00 for disman@ietf.org; Wed, 21 Jan 2004 11:35:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjLIu-0006Je-00 for disman@ietf.org; Wed, 21 Jan 2004 11:34:09 -0500 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by ietf-mx with esmtp (Exim 4.12) id 1AjLHy-0006F9-00 for disman@ietf.org; Wed, 21 Jan 2004 11:33:11 -0500 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0LGX07R026418 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 21 Jan 2004 17:33:00 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0LGX0Cw001089; Wed, 21 Jan 2004 17:33:00 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) id i0LGX0QE001086; Wed, 21 Jan 2004 17:33:00 +0100 Message-Id: <200401211633.i0LGX0QE001086@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: quittek@ccrle.nec.de CC: disman@ietf.org In-reply-to: <2147483647.1074702954@[10.1.1.171]> (message from Juergen Quittek on Wed, 21 Jan 2004 16:35:54 +0100) Subject: Re: [Disman] ping-mib-1 References: <2147483647.1074702954@[10.1.1.171]> X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 17:33:00 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 >>>>> Juergen Quittek writes: Juergen> Dear all, Juergen> Here is the first one. In the PING MIB there is a Juergen> contradiction in the definition of Juergen> pingCtlTrapGeneration [...] Juergen> Does anyone has a strong preference or another solution of Juergen> this issue? I think the correct DEFAL to add is DEFVAL { {} } -- No bits set. and the text needs to be modified to talk about a bit string with no bits set or a zero-length bit string or whatever you prefer. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From disman-admin@ietf.org Wed Jan 21 11:40:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29029 for ; Wed, 21 Jan 2004 11:40:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLOd-0003Kx-KP; Wed, 21 Jan 2004 11:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLNs-0003AO-6L for disman@optimus.ietf.org; Wed, 21 Jan 2004 11:39:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29011 for ; Wed, 21 Jan 2004 11:39:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjLNr-0006Yq-00 for disman@ietf.org; Wed, 21 Jan 2004 11:39:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjLMy-0006WR-00 for disman@ietf.org; Wed, 21 Jan 2004 11:38:20 -0500 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by ietf-mx with esmtp (Exim 4.12) id 1AjLME-0006Tp-00 for disman@ietf.org; Wed, 21 Jan 2004 11:37:34 -0500 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0LGbU7R028348 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 21 Jan 2004 17:37:30 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0LGbTCw001183; Wed, 21 Jan 2004 17:37:29 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) id i0LGbTQE001180; Wed, 21 Jan 2004 17:37:29 +0100 Message-Id: <200401211637.i0LGbTQE001180@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: quittek@ccrle.nec.de CC: disman@ietf.org In-reply-to: <2147483647.1074703989@[10.1.1.171]> (message from Juergen Quittek on Wed, 21 Jan 2004 16:53:09 +0100) Subject: Re: [Disman] traceroute-mib-1 References: <2147483647.1074703989@[10.1.1.171]> X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 17:37:29 +0100 >>>>> Juergen Quittek writes: [...] Juergen> Does anyone have an understanding of the term "complete path" Juergen> that differs from the following? Juergen> The date and time when the last complete path was determined. Juergen> A path is complete if the IP address of each hop along the Juergen> path has been detected." Some nodes do not send ICMP responses or they are blocked somewhere so it happens with ordinary traceroutes that you see *s instead of IP numbers for a certain hop. (Sure, there is a timeout associated with this somehow.) If I take your addition by the word, I might conclude that a traceroute in never completes in case there is node in the path which does not send me ICMP responses. In other words, I do not think that the clarification helps. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From disman-admin@ietf.org Wed Jan 21 11:42:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29135 for ; Wed, 21 Jan 2004 11:42:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLQW-0003QW-Ml; Wed, 21 Jan 2004 11:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLPq-0003Pf-1z for disman@optimus.ietf.org; Wed, 21 Jan 2004 11:41:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29095 for ; Wed, 21 Jan 2004 11:41:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjLPo-0006ew-00 for disman@ietf.org; Wed, 21 Jan 2004 11:41:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjLOs-0006cG-00 for disman@ietf.org; Wed, 21 Jan 2004 11:40:19 -0500 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by ietf-mx with esmtp (Exim 4.12) id 1AjLOR-0006ZT-00 for disman@ietf.org; Wed, 21 Jan 2004 11:39:51 -0500 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0LGdl7R028914 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 21 Jan 2004 17:39:47 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0LGdlCw001230; Wed, 21 Jan 2004 17:39:47 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) id i0LGdlYU001227; Wed, 21 Jan 2004 17:39:47 +0100 Message-Id: <200401211639.i0LGdlYU001227@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: quittek@ccrle.nec.de CC: disman@ietf.org In-reply-to: <2147483647.1074704559@[10.1.1.171]> (message from Juergen Quittek on Wed, 21 Jan 2004 17:02:39 +0100) Subject: Re: [Disman] lookup-mib-1 References: <2147483647.1074704559@[10.1.1.171]> X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 17:39:47 +0100 >>>>> Juergen Quittek writes: [...] Juergen> My question is: Does adding this (obvious) value to the Juergen> SYNTAX clause require the document to start again as proposed Juergen> standard or can it progress with this change towards draft Juergen> standard? For me, this is a very clear bug fix which should not ring any bells (also during MIB review). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From exim@www1.ietf.org Wed Jan 21 11:42:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29152 for ; Wed, 21 Jan 2004 11:42:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLQf-0003S9-SW for disman-archive@odin.ietf.org; Wed, 21 Jan 2004 11:42:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LGg9La013267 for disman-archive@odin.ietf.org; Wed, 21 Jan 2004 11:42:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLQf-0003Ru-PM for disman-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 11:42:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29120 for ; Wed, 21 Jan 2004 11:42:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjLQe-0006gY-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 11:42:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjLPh-0006dw-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 11:41:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjLOl-0006av-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 11:40:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLOd-0003Kx-KP; Wed, 21 Jan 2004 11:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLNs-0003AO-6L for disman@optimus.ietf.org; Wed, 21 Jan 2004 11:39:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29011 for ; Wed, 21 Jan 2004 11:39:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjLNr-0006Yq-00 for disman@ietf.org; Wed, 21 Jan 2004 11:39:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjLMy-0006WR-00 for disman@ietf.org; Wed, 21 Jan 2004 11:38:20 -0500 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by ietf-mx with esmtp (Exim 4.12) id 1AjLME-0006Tp-00 for disman@ietf.org; Wed, 21 Jan 2004 11:37:34 -0500 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0LGbU7R028348 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 21 Jan 2004 17:37:30 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0LGbTCw001183; Wed, 21 Jan 2004 17:37:29 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) id i0LGbTQE001180; Wed, 21 Jan 2004 17:37:29 +0100 Message-Id: <200401211637.i0LGbTQE001180@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: quittek@ccrle.nec.de CC: disman@ietf.org In-reply-to: <2147483647.1074703989@[10.1.1.171]> (message from Juergen Quittek on Wed, 21 Jan 2004 16:53:09 +0100) Subject: Re: [Disman] traceroute-mib-1 References: <2147483647.1074703989@[10.1.1.171]> X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 17:37:29 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 >>>>> Juergen Quittek writes: [...] Juergen> Does anyone have an understanding of the term "complete path" Juergen> that differs from the following? Juergen> The date and time when the last complete path was determined. Juergen> A path is complete if the IP address of each hop along the Juergen> path has been detected." Some nodes do not send ICMP responses or they are blocked somewhere so it happens with ordinary traceroutes that you see *s instead of IP numbers for a certain hop. (Sure, there is a timeout associated with this somehow.) If I take your addition by the word, I might conclude that a traceroute in never completes in case there is node in the path which does not send me ICMP responses. In other words, I do not think that the clarification helps. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From exim@www1.ietf.org Wed Jan 21 11:43:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29179 for ; Wed, 21 Jan 2004 11:43:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLRf-0003Wb-8N for disman-archive@odin.ietf.org; Wed, 21 Jan 2004 11:43:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LGhB4B013543 for disman-archive@odin.ietf.org; Wed, 21 Jan 2004 11:43:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLRf-0003WM-52 for disman-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 11:43:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29176 for ; Wed, 21 Jan 2004 11:43:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjLRe-0006iN-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 11:43:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjLQh-0006h7-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 11:42:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjLQW-0006fe-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 11:42:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLQW-0003QW-Ml; Wed, 21 Jan 2004 11:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjLPq-0003Pf-1z for disman@optimus.ietf.org; Wed, 21 Jan 2004 11:41:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29095 for ; Wed, 21 Jan 2004 11:41:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjLPo-0006ew-00 for disman@ietf.org; Wed, 21 Jan 2004 11:41:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjLOs-0006cG-00 for disman@ietf.org; Wed, 21 Jan 2004 11:40:19 -0500 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by ietf-mx with esmtp (Exim 4.12) id 1AjLOR-0006ZT-00 for disman@ietf.org; Wed, 21 Jan 2004 11:39:51 -0500 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0LGdl7R028914 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 21 Jan 2004 17:39:47 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0LGdlCw001230; Wed, 21 Jan 2004 17:39:47 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) id i0LGdlYU001227; Wed, 21 Jan 2004 17:39:47 +0100 Message-Id: <200401211639.i0LGdlYU001227@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: quittek@ccrle.nec.de CC: disman@ietf.org In-reply-to: <2147483647.1074704559@[10.1.1.171]> (message from Juergen Quittek on Wed, 21 Jan 2004 17:02:39 +0100) Subject: Re: [Disman] lookup-mib-1 References: <2147483647.1074704559@[10.1.1.171]> X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 17:39:47 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 >>>>> Juergen Quittek writes: [...] Juergen> My question is: Does adding this (obvious) value to the Juergen> SYNTAX clause require the document to start again as proposed Juergen> standard or can it progress with this change towards draft Juergen> standard? For me, this is a very clear bug fix which should not ring any bells (also during MIB review). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From disman-admin@ietf.org Wed Jan 21 15:37:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07256 for ; Wed, 21 Jan 2004 15:37:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjP5w-0000uI-OC; Wed, 21 Jan 2004 15:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjP5J-0000oY-NH for disman@optimus.ietf.org; Wed, 21 Jan 2004 15:36:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07176 for ; Wed, 21 Jan 2004 15:36:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjP5I-0000T9-00 for disman@ietf.org; Wed, 21 Jan 2004 15:36:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjP4P-0000R0-00 for disman@ietf.org; Wed, 21 Jan 2004 15:35:26 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AjP3j-0000Lt-00 for disman@ietf.org; Wed, 21 Jan 2004 15:34:43 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0LKYCQ12722 for ; Wed, 21 Jan 2004 15:34:12 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Jan 2004 15:34:12 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409E2BD38@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 15:34:09 -0500 Hi Based on some further suggestions from Bert, here is the latest proposal. ---- The following is the proposed resolution to IESG-1 and IESG-5 In the description for IanaItuProbableCause, replace the description "ITU probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAItuProbableCause values. Values of IANAItuProbableCause less than 1024 are reserved for causes that correspond to ITU probable cause. IANAItuProbableCause of 0 is reserved for special purposes and therefore cannot be assigned. See http://www.iana.org" With " ITU-T probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure syntactic uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of the enumerations in this TC. IANAItuProbableCause value of 0 is reserved for special purposes and MUST NOT be assigned. Values of IANAItuProbableCause in the range 1 to 1023 are reserved for causes that correspond to ITU-T probable cause. All other requests for new causes will be handled on a first-come, first served basis and will be assigned enumeration values starting with 1025. Request should come in the form of well-formed SMI [RFC2578] for enumeration names that are unique and sufficiently descriptive. While some effort will be taken to ensure that new probable causes do not conceptually duplicate existing probable causes it is acknowledged that the existence of conceptual duplicates in the starting probable cause list is an known industry reality. To aid IANA in the administration of probable cause names and values, the OPS Area Director will appoint one or more experts to help review requests. See http://www.iana.org " Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Tuesday, January 20, 2004 4:45 PM To: disman@ietf.org Subject: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 2) Hi Here is an updated proposed resolution based on Bert's comments ----- The following is the proposed resolution to IESG-1 and IESG-5 In the description for IanaItuProbableCause, replace the description "ITU probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAItuProbableCause values. Values of IANAItuProbableCause less than 1024 are reserved for causes that correspond to ITU probable cause. IANAItuProbableCause of 0 is reserved for special purposes and therefore cannot be assigned. See http://www.iana.org" With " ITU-T probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure syntactic uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers. IANAItuProbableCause of 0 is reserved for special purposes and MUST NOT be assigned. Values of IANAItuProbableCause in the range 1 to 1023 are reserved for causes that correspond to ITU-T probable cause. All other requests for new causes will be handled on a first-come, first served basis and will be assigned enumeration values starting with 1025. Request should come in the form of well-formed SMI [RFC2578] for enumeration names that are unique and sufficiently descriptive. While some effort will be taken to ensure that new probable causes do not conceptually duplicate existing probable causes it is acknowledged that the existence of conceptual duplicates in the starting probable cause list is an known industry reality. To aid IANA in the administration of probable cause names and values, the Management Area Director will appoint an expert to help review requests. See http://www.iana.org " Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From exim@www1.ietf.org Wed Jan 21 15:38:51 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07347 for ; Wed, 21 Jan 2004 15:38:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjP7H-0001Q7-73 for disman-archive@odin.ietf.org; Wed, 21 Jan 2004 15:38:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LKcN7E005455 for disman-archive@odin.ietf.org; Wed, 21 Jan 2004 15:38:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjP7F-0001Pt-Ms for disman-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 15:38:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07312 for ; Wed, 21 Jan 2004 15:38:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjP7E-0000Yh-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 15:38:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjP6L-0000Wf-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 15:37:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjP5y-0000UE-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 15:37:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjP5w-0000uI-OC; Wed, 21 Jan 2004 15:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjP5J-0000oY-NH for disman@optimus.ietf.org; Wed, 21 Jan 2004 15:36:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07176 for ; Wed, 21 Jan 2004 15:36:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjP5I-0000T9-00 for disman@ietf.org; Wed, 21 Jan 2004 15:36:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjP4P-0000R0-00 for disman@ietf.org; Wed, 21 Jan 2004 15:35:26 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AjP3j-0000Lt-00 for disman@ietf.org; Wed, 21 Jan 2004 15:34:43 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0LKYCQ12722 for ; Wed, 21 Jan 2004 15:34:12 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Jan 2004 15:34:12 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409E2BD38@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Jan 2004 15:34:09 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Based on some further suggestions from Bert, here is the latest proposal. ---- The following is the proposed resolution to IESG-1 and IESG-5 In the description for IanaItuProbableCause, replace the description "ITU probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAItuProbableCause values. Values of IANAItuProbableCause less than 1024 are reserved for causes that correspond to ITU probable cause. IANAItuProbableCause of 0 is reserved for special purposes and therefore cannot be assigned. See http://www.iana.org" With " ITU-T probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure syntactic uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of the enumerations in this TC. IANAItuProbableCause value of 0 is reserved for special purposes and MUST NOT be assigned. Values of IANAItuProbableCause in the range 1 to 1023 are reserved for causes that correspond to ITU-T probable cause. All other requests for new causes will be handled on a first-come, first served basis and will be assigned enumeration values starting with 1025. Request should come in the form of well-formed SMI [RFC2578] for enumeration names that are unique and sufficiently descriptive. While some effort will be taken to ensure that new probable causes do not conceptually duplicate existing probable causes it is acknowledged that the existence of conceptual duplicates in the starting probable cause list is an known industry reality. To aid IANA in the administration of probable cause names and values, the OPS Area Director will appoint one or more experts to help review requests. See http://www.iana.org " Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Tuesday, January 20, 2004 4:45 PM To: disman@ietf.org Subject: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 2) Hi Here is an updated proposed resolution based on Bert's comments ----- The following is the proposed resolution to IESG-1 and IESG-5 In the description for IanaItuProbableCause, replace the description "ITU probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAItuProbableCause values. Values of IANAItuProbableCause less than 1024 are reserved for causes that correspond to ITU probable cause. IANAItuProbableCause of 0 is reserved for special purposes and therefore cannot be assigned. See http://www.iana.org" With " ITU-T probable cause values. Duplicate values defined in X.733 are appended with X733 to ensure syntactic uniqueness. Probable cause value 0 is reserved for special purposes. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers. IANAItuProbableCause of 0 is reserved for special purposes and MUST NOT be assigned. Values of IANAItuProbableCause in the range 1 to 1023 are reserved for causes that correspond to ITU-T probable cause. All other requests for new causes will be handled on a first-come, first served basis and will be assigned enumeration values starting with 1025. Request should come in the form of well-formed SMI [RFC2578] for enumeration names that are unique and sufficiently descriptive. While some effort will be taken to ensure that new probable causes do not conceptually duplicate existing probable causes it is acknowledged that the existence of conceptual duplicates in the starting probable cause list is an known industry reality. To aid IANA in the administration of probable cause names and values, the Management Area Director will appoint an expert to help review requests. See http://www.iana.org " Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From disman-admin@ietf.org Wed Jan 21 18:51:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18383 for ; Wed, 21 Jan 2004 18:51:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjS7i-00027m-31; Wed, 21 Jan 2004 18:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjS78-000270-51 for disman@optimus.ietf.org; Wed, 21 Jan 2004 18:50:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18362 for ; Wed, 21 Jan 2004 18:50:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjS75-0003Pm-00 for disman@ietf.org; Wed, 21 Jan 2004 18:50:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjS66-0003OF-00 for disman@ietf.org; Wed, 21 Jan 2004 18:49:22 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AjS5D-0003Le-00 for disman@ietf.org; Wed, 21 Jan 2004 18:48:28 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0LNlqkC029791 for ; Thu, 22 Jan 2004 00:47:53 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0LNlmD1029790 for ; Thu, 22 Jan 2004 00:47:48 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0LNllkA029788; Thu, 22 Jan 2004 00:47:48 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A8345FBF4A; Thu, 22 Jan 2004 00:47:45 +0100 (CET) From: Juergen Quittek To: Juergen Schoenwaelder Cc: disman@ietf.org Subject: Re: [Disman] traceroute-mib-1 Message-ID: <2147483647.1074732470@[10.1.1.26]> In-Reply-To: <200401211637.i0LGbTQE001180@hansa.ibr.cs.tu-bs.de> References: <2147483647.1074703989@[10.1.1.171]> <200401211637.i0LGbTQE001180@hansa.ibr.cs.tu-bs.de> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Jan 2004 00:47:50 +0100 Content-Transfer-Encoding: 7bit --On 21.01.2004 17:37 Uhr +0100 Juergen Schoenwaelder wrote: > >>>>>> Juergen Quittek writes: > > [...] > > Juergen> Does anyone have an understanding of the term "complete path" > Juergen> that differs from the following? > > Juergen> The date and time when the last complete path was determined. > Juergen> A path is complete if the IP address of each hop along the > Juergen> path has been detected." > > Some nodes do not send ICMP responses or they are blocked somewhere > so it happens with ordinary traceroutes that you see *s instead of > IP numbers for a certain hop. (Sure, there is a timeout associated > with this somehow.) If I take your addition by the word, I might > conclude that a traceroute in never completes in case there is node > in the path which does not send me ICMP responses. But otherwise, wouldn't all paths be complete paths? What would be an incomplete path? In the PING MIB a good probe is defined as pingResultsLastGoodProbe OBJECT-TYPE^M SYNTAX DateAndTime^M MAX-ACCESS read-only^M STATUS current^M DESCRIPTION^M "Date and time when the last response was received for^M a probe."^M ::= { pingResultsEntry 10 }^M Wouldn't a good path be a path for which responses were received from all hops? > In other words, I do not think that the clarification helps. Now I'm sure there is one needed. Juergen > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > > From exim@www1.ietf.org Wed Jan 21 18:52:57 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18413 for ; Wed, 21 Jan 2004 18:52:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjS98-0002GC-Ts for disman-archive@odin.ietf.org; Wed, 21 Jan 2004 18:52:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LNqUXU008682 for disman-archive@odin.ietf.org; Wed, 21 Jan 2004 18:52:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjS98-0002Fx-PS for disman-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 18:52:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18410 for ; Wed, 21 Jan 2004 18:52:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjS95-0003Ue-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 18:52:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjS88-0003Ss-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 18:51:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjS7h-0003Ql-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 18:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjS7i-00027m-31; Wed, 21 Jan 2004 18:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjS78-000270-51 for disman@optimus.ietf.org; Wed, 21 Jan 2004 18:50:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18362 for ; Wed, 21 Jan 2004 18:50:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjS75-0003Pm-00 for disman@ietf.org; Wed, 21 Jan 2004 18:50:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjS66-0003OF-00 for disman@ietf.org; Wed, 21 Jan 2004 18:49:22 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AjS5D-0003Le-00 for disman@ietf.org; Wed, 21 Jan 2004 18:48:28 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0LNlqkC029791 for ; Thu, 22 Jan 2004 00:47:53 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0LNlmD1029790 for ; Thu, 22 Jan 2004 00:47:48 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0LNllkA029788; Thu, 22 Jan 2004 00:47:48 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A8345FBF4A; Thu, 22 Jan 2004 00:47:45 +0100 (CET) From: Juergen Quittek To: Juergen Schoenwaelder Cc: disman@ietf.org Subject: Re: [Disman] traceroute-mib-1 Message-ID: <2147483647.1074732470@[10.1.1.26]> In-Reply-To: <200401211637.i0LGbTQE001180@hansa.ibr.cs.tu-bs.de> References: <2147483647.1074703989@[10.1.1.171]> <200401211637.i0LGbTQE001180@hansa.ibr.cs.tu-bs.de> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Jan 2004 00:47:50 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On 21.01.2004 17:37 Uhr +0100 Juergen Schoenwaelder wrote: > >>>>>> Juergen Quittek writes: > > [...] > > Juergen> Does anyone have an understanding of the term "complete path" > Juergen> that differs from the following? > > Juergen> The date and time when the last complete path was determined. > Juergen> A path is complete if the IP address of each hop along the > Juergen> path has been detected." > > Some nodes do not send ICMP responses or they are blocked somewhere > so it happens with ordinary traceroutes that you see *s instead of > IP numbers for a certain hop. (Sure, there is a timeout associated > with this somehow.) If I take your addition by the word, I might > conclude that a traceroute in never completes in case there is node > in the path which does not send me ICMP responses. But otherwise, wouldn't all paths be complete paths? What would be an incomplete path? In the PING MIB a good probe is defined as pingResultsLastGoodProbe OBJECT-TYPE^M SYNTAX DateAndTime^M MAX-ACCESS read-only^M STATUS current^M DESCRIPTION^M "Date and time when the last response was received for^M a probe."^M ::= { pingResultsEntry 10 }^M Wouldn't a good path be a path for which responses were received from all hops? > In other words, I do not think that the clarification helps. Now I'm sure there is one needed. Juergen > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > > From disman-admin@ietf.org Wed Jan 21 20:37:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20879 for ; Wed, 21 Jan 2004 20:37:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjTmG-0007KE-DN; Wed, 21 Jan 2004 20:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjTlr-0007Hm-17 for disman@optimus.ietf.org; Wed, 21 Jan 2004 20:36:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20857 for ; Wed, 21 Jan 2004 20:36:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjTlo-0007Uj-00 for disman@ietf.org; Wed, 21 Jan 2004 20:36:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjTks-0007SE-00 for disman@ietf.org; Wed, 21 Jan 2004 20:35:34 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AjTkB-0007Nk-00 for disman@ietf.org; Wed, 21 Jan 2004 20:34:51 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0M1YKkC030313 for ; Thu, 22 Jan 2004 02:34:21 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0M1YGjw030312 for ; Thu, 22 Jan 2004 02:34:16 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0M1YGkA030310; Thu, 22 Jan 2004 02:34:16 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 8F9DEFBFCE; Thu, 22 Jan 2004 02:34:13 +0100 (CET) From: Juergen Quittek To: Juergen Schoenwaelder Cc: disman@ietf.org Subject: Re: [Disman] ping-mib-1 Message-ID: <2147483647.1074738858@[10.1.1.26]> In-Reply-To: <200401211633.i0LGX0QE001086@hansa.ibr.cs.tu-bs.de> References: <2147483647.1074702954@[10.1.1.171]> <200401211633.i0LGX0QE001086@hansa.ibr.cs.tu-bs.de> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Jan 2004 02:34:19 +0100 Content-Transfer-Encoding: 7bit Juergen, --On 21.01.2004 17:33 Uhr +0100 Juergen Schoenwaelder wrote: > >>>>>> Juergen Quittek writes: > > Juergen> Dear all, > > Juergen> Here is the first one. In the PING MIB there is a > Juergen> contradiction in the definition of > Juergen> pingCtlTrapGeneration > > [...] > > Juergen> Does anyone has a strong preference or another solution of > Juergen> this issue? > > I think the correct DEFAL to add is > > DEFVAL { {} } -- No bits set. > > and the text needs to be modified to talk about a bit string with > no bits set or a zero-length bit string or whatever you prefer. I see. 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 > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > > From exim@www1.ietf.org Wed Jan 21 20:39:05 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20977 for ; Wed, 21 Jan 2004 20:39:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjTnp-0007jA-Ew for disman-archive@odin.ietf.org; Wed, 21 Jan 2004 20:38:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M1cb0M029698 for disman-archive@odin.ietf.org; Wed, 21 Jan 2004 20:38:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjTnp-0007iv-8f for disman-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 20:38:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20970 for ; Wed, 21 Jan 2004 20:38:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjTnm-0007d4-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 20:38:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjTn0-0007ak-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 20:37:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjTmG-0007WX-00 for disman-web-archive@ietf.org; Wed, 21 Jan 2004 20:37:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjTmG-0007KE-DN; Wed, 21 Jan 2004 20:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjTlr-0007Hm-17 for disman@optimus.ietf.org; Wed, 21 Jan 2004 20:36:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20857 for ; Wed, 21 Jan 2004 20:36:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjTlo-0007Uj-00 for disman@ietf.org; Wed, 21 Jan 2004 20:36:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjTks-0007SE-00 for disman@ietf.org; Wed, 21 Jan 2004 20:35:34 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AjTkB-0007Nk-00 for disman@ietf.org; Wed, 21 Jan 2004 20:34:51 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0M1YKkC030313 for ; Thu, 22 Jan 2004 02:34:21 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0M1YGjw030312 for ; Thu, 22 Jan 2004 02:34:16 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0M1YGkA030310; Thu, 22 Jan 2004 02:34:16 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 8F9DEFBFCE; Thu, 22 Jan 2004 02:34:13 +0100 (CET) From: Juergen Quittek To: Juergen Schoenwaelder Cc: disman@ietf.org Subject: Re: [Disman] ping-mib-1 Message-ID: <2147483647.1074738858@[10.1.1.26]> In-Reply-To: <200401211633.i0LGX0QE001086@hansa.ibr.cs.tu-bs.de> References: <2147483647.1074702954@[10.1.1.171]> <200401211633.i0LGX0QE001086@hansa.ibr.cs.tu-bs.de> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Jan 2004 02:34:19 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Juergen, --On 21.01.2004 17:33 Uhr +0100 Juergen Schoenwaelder wrote: > >>>>>> Juergen Quittek writes: > > Juergen> Dear all, > > Juergen> Here is the first one. In the PING MIB there is a > Juergen> contradiction in the definition of > Juergen> pingCtlTrapGeneration > > [...] > > Juergen> Does anyone has a strong preference or another solution of > Juergen> this issue? > > I think the correct DEFAL to add is > > DEFVAL { {} } -- No bits set. > > and the text needs to be modified to talk about a bit string with > no bits set or a zero-length bit string or whatever you prefer. I see. 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 > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > > From disman-admin@ietf.org Thu Jan 22 07:42:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19517 for ; Thu, 22 Jan 2004 07:42:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aje9p-0006nI-Bi; Thu, 22 Jan 2004 07:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aje9b-0006n5-KT for disman@optimus.ietf.org; Thu, 22 Jan 2004 07:41:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19514 for ; Thu, 22 Jan 2004 07:41:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aje9a-0000b2-00 for disman@ietf.org; Thu, 22 Jan 2004 07:41:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aje8d-0000a5-00 for disman@ietf.org; Thu, 22 Jan 2004 07:40:48 -0500 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by ietf-mx with esmtp (Exim 4.12) id 1Aje8N-0000ZH-00 for disman@ietf.org; Thu, 22 Jan 2004 07:40:31 -0500 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0MCeFLU031040 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 22 Jan 2004 13:40:15 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0MCeFCw016641; Thu, 22 Jan 2004 13:40:15 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) id i0MCeC3b016637; Thu, 22 Jan 2004 13:40:12 +0100 Message-Id: <200401221240.i0MCeC3b016637@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: quittek@ccrle.nec.de CC: disman@ietf.org In-reply-to: <2147483647.1074732470@[10.1.1.26]> (message from Juergen Quittek on Thu, 22 Jan 2004 00:47:50 +0100) Subject: Re: [Disman] traceroute-mib-1 References: <2147483647.1074703989@[10.1.1.171]> <200401211637.i0LGbTQE001180@hansa.ibr.cs.tu-bs.de> <2147483647.1074732470@[10.1.1.26]> X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Jan 2004 13:40:12 +0100 >>>>> Juergen Quittek writes: Juergen> Wouldn't a good path be a path for which responses were Juergen> received from all hops? Sure, in theory. But in reality, there are hops in the path which will simply not respond. So a good path is a path for which responses or timeouts have been received for all hops. (And again, if you hit an unfriendly firewall somewhere on the path, you might end up increasing the ttl until you reach the max. ttl value.) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From exim@www1.ietf.org Thu Jan 22 07:45:47 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19866 for ; Thu, 22 Jan 2004 07:45:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjeCz-00074d-Ng for disman-archive@odin.ietf.org; Thu, 22 Jan 2004 07:45:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MCjHWA027187 for disman-archive@odin.ietf.org; Thu, 22 Jan 2004 07:45:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjeCz-00074Q-KX for disman-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 07:45:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19833 for ; Thu, 22 Jan 2004 07:45:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjeCy-00012N-00 for disman-web-archive@ietf.org; Thu, 22 Jan 2004 07:45:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjeBv-0000rj-00 for disman-web-archive@ietf.org; Thu, 22 Jan 2004 07:44:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aje9r-0000dA-00 for disman-web-archive@ietf.org; Thu, 22 Jan 2004 07:42:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aje9p-0006nI-Bi; Thu, 22 Jan 2004 07:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aje9b-0006n5-KT for disman@optimus.ietf.org; Thu, 22 Jan 2004 07:41:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19514 for ; Thu, 22 Jan 2004 07:41:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aje9a-0000b2-00 for disman@ietf.org; Thu, 22 Jan 2004 07:41:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aje8d-0000a5-00 for disman@ietf.org; Thu, 22 Jan 2004 07:40:48 -0500 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by ietf-mx with esmtp (Exim 4.12) id 1Aje8N-0000ZH-00 for disman@ietf.org; Thu, 22 Jan 2004 07:40:31 -0500 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0MCeFLU031040 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 22 Jan 2004 13:40:15 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0MCeFCw016641; Thu, 22 Jan 2004 13:40:15 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) id i0MCeC3b016637; Thu, 22 Jan 2004 13:40:12 +0100 Message-Id: <200401221240.i0MCeC3b016637@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: quittek@ccrle.nec.de CC: disman@ietf.org In-reply-to: <2147483647.1074732470@[10.1.1.26]> (message from Juergen Quittek on Thu, 22 Jan 2004 00:47:50 +0100) Subject: Re: [Disman] traceroute-mib-1 References: <2147483647.1074703989@[10.1.1.171]> <200401211637.i0LGbTQE001180@hansa.ibr.cs.tu-bs.de> <2147483647.1074732470@[10.1.1.26]> X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Jan 2004 13:40:12 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 >>>>> Juergen Quittek writes: Juergen> Wouldn't a good path be a path for which responses were Juergen> received from all hops? Sure, in theory. But in reality, there are hops in the path which will simply not respond. So a good path is a path for which responses or timeouts have been received for all hops. (And again, if you hit an unfriendly firewall somewhere on the path, you might end up increasing the ttl until you reach the max. ttl value.) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From disman-admin@ietf.org Thu Jan 22 13:38:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03188 for ; Thu, 22 Jan 2004 13:38:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjjiL-0006jb-A0; Thu, 22 Jan 2004 13:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjjJW-0004eG-3y for disman@optimus.ietf.org; Thu, 22 Jan 2004 13:12:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02207 for ; Thu, 22 Jan 2004 13:12:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjjJK-0001hf-00 for disman@ietf.org; Thu, 22 Jan 2004 13:12:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjjFt-0001XY-00 for disman@ietf.org; Thu, 22 Jan 2004 13:08:38 -0500 Received: from shockwave.systems.pipex.net ([62.241.160.9]) by ietf-mx with esmtp (Exim 4.12) id 1AjjDT-0001OX-00 for disman@ietf.org; Thu, 22 Jan 2004 13:06:07 -0500 Received: from tom3 (1Cust149.tnt1.lnd4.gbr.da.uu.net [62.188.130.149]) by shockwave.systems.pipex.net (Postfix) with SMTP id D9F1F1C00166; Thu, 22 Jan 2004 18:05:09 +0000 (GMT) Message-ID: <000501c3e112$28254d20$0301a8c0@tom3> Reply-To: "tom petch" From: "tom petch" To: "Sharon Chisholm" , Subject: Re: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Jan 2004 18:00:46 -0000 Content-Transfer-Encoding: 7bit Sharon no problems with the new text but :-) 1) where does 1024(other) sit in this? is it other for the whole range, other for 1 to1023, other for 1025 - nnnn? 2) is there a similar issue with IANAItuEventType do we need a similar expanded description for that? 3) the IANAItuEventType ::= TEXTUAL-CONVENTION has in its description The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAEventType values. See http://www.iana.org " I think an Itu has got lost from there. 4) I never have understood the X733 appendage; what is the duplication between which two (or more) lists where? I assume the whole list is present in X.733 as well as in this document so where else? Tom Petch nwnetworks@dial.pipex.com -----Original Message----- From: Sharon Chisholm To: disman@ietf.org Date: 21 January 2004 20:37 Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) >Hi > >Based on some further suggestions from Bert, here is the latest proposal. > >---- >The following is the proposed resolution to IESG-1 and IESG-5 > >In the description for IanaItuProbableCause, replace the description > >"ITU probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure uniqueness. Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers, including > various SNMP-related numbers, and specifically, new > IANAItuProbableCause values. Values of > IANAItuProbableCause less than 1024 are reserved for causes > that correspond to ITU probable cause. IANAItuProbableCause > of 0 is reserved for special purposes and therefore cannot > be assigned. See http://www.iana.org" > >With > >" ITU-T probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure syntactic uniqueness. Probable >cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of the enumerations in this TC. > IANAItuProbableCause value of 0 is reserved for special > purposes and MUST NOT be assigned. > > Values of IANAItuProbableCause in the range 1 to 1023 are >reserved > for causes that correspond to ITU-T probable cause. > > All other requests for new causes will be handled on a >first-come, > first served basis and will be assigned enumeration values >starting > with 1025. > > Request should come in the form of well-formed SMI [RFC2578] > for enumeration names that are unique and sufficiently >descriptive. > > While some effort will be taken to ensure that new probable >causes > do not conceptually duplicate existing probable causes it is > acknowledged that the existence of conceptual duplicates in the > starting probable cause list is an known industry reality. > > To aid IANA in the administration of probable cause names and >values, > the OPS Area Director will appoint one or more experts to help >review > requests. > > See http://www.iana.org > > " > >Sharon > >-----Original Message----- >From: Chisholm, Sharon [CAR:0S00:EXCH] >Sent: Tuesday, January 20, 2004 4:45 PM >To: disman@ietf.org >Subject: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 2) > > >Hi > >Here is an updated proposed resolution based on Bert's comments > >----- > >The following is the proposed resolution to IESG-1 and IESG-5 > >In the description for IanaItuProbableCause, replace the description > >"ITU probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure uniqueness. Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers, including > various SNMP-related numbers, and specifically, new > IANAItuProbableCause values. Values of > IANAItuProbableCause less than 1024 are reserved for causes > that correspond to ITU probable cause. IANAItuProbableCause > of 0 is reserved for special purposes and therefore cannot > be assigned. See http://www.iana.org" > >With > >" ITU-T probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure syntactic uniqueness. Probable >cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers. IANAItuProbableCause > of 0 is reserved for special purposes and MUST NOT > be assigned. > > Values of IANAItuProbableCause in the range 1 to 1023 are >reserved > for causes that correspond to ITU-T probable cause. All other >requests > for new causes will be handled on a first-come, first served >basis and > will be assigned enumeration values starting with 1025. Request >should > come in the form of well-formed SMI [RFC2578] for enumeration >names > that are unique and sufficiently descriptive. > > While some effort will be taken to ensure that new probable >causes > do not conceptually duplicate existing probable causes it is > acknowledged that the existence of conceptual duplicates in the > starting probable cause list is an known industry reality. > > To aid IANA in the administration of probable cause names and >values, > the Management Area Director will appoint an expert to help >review > requests. > > See http://www.iana.org > > " > >Sharon Chisholm >Portfolio Integration >Nortel Networks >Ottawa, Canada > > From exim@www1.ietf.org Thu Jan 22 13:40:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03307 for ; Thu, 22 Jan 2004 13:40:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjjkG-00075M-1c for disman-archive@odin.ietf.org; Thu, 22 Jan 2004 13:40:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MIe0kl027232 for disman-archive@odin.ietf.org; Thu, 22 Jan 2004 13:40:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjjkF-000759-UT for disman-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 13:39:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03249 for ; Thu, 22 Jan 2004 13:39:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjjkD-0003DU-00 for disman-web-archive@ietf.org; Thu, 22 Jan 2004 13:39:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjjjG-0003B5-00 for disman-web-archive@ietf.org; Thu, 22 Jan 2004 13:38:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjjiL-00038p-00 for disman-web-archive@ietf.org; Thu, 22 Jan 2004 13:38:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjjiL-0006jb-A0; Thu, 22 Jan 2004 13:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjjJW-0004eG-3y for disman@optimus.ietf.org; Thu, 22 Jan 2004 13:12:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02207 for ; Thu, 22 Jan 2004 13:12:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjjJK-0001hf-00 for disman@ietf.org; Thu, 22 Jan 2004 13:12:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjjFt-0001XY-00 for disman@ietf.org; Thu, 22 Jan 2004 13:08:38 -0500 Received: from shockwave.systems.pipex.net ([62.241.160.9]) by ietf-mx with esmtp (Exim 4.12) id 1AjjDT-0001OX-00 for disman@ietf.org; Thu, 22 Jan 2004 13:06:07 -0500 Received: from tom3 (1Cust149.tnt1.lnd4.gbr.da.uu.net [62.188.130.149]) by shockwave.systems.pipex.net (Postfix) with SMTP id D9F1F1C00166; Thu, 22 Jan 2004 18:05:09 +0000 (GMT) Message-ID: <000501c3e112$28254d20$0301a8c0@tom3> Reply-To: "tom petch" From: "tom petch" To: "Sharon Chisholm" , Subject: Re: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Jan 2004 18:00:46 -0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sharon no problems with the new text but :-) 1) where does 1024(other) sit in this? is it other for the whole range, other for 1 to1023, other for 1025 - nnnn? 2) is there a similar issue with IANAItuEventType do we need a similar expanded description for that? 3) the IANAItuEventType ::= TEXTUAL-CONVENTION has in its description The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAEventType values. See http://www.iana.org " I think an Itu has got lost from there. 4) I never have understood the X733 appendage; what is the duplication between which two (or more) lists where? I assume the whole list is present in X.733 as well as in this document so where else? Tom Petch nwnetworks@dial.pipex.com -----Original Message----- From: Sharon Chisholm To: disman@ietf.org Date: 21 January 2004 20:37 Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) >Hi > >Based on some further suggestions from Bert, here is the latest proposal. > >---- >The following is the proposed resolution to IESG-1 and IESG-5 > >In the description for IanaItuProbableCause, replace the description > >"ITU probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure uniqueness. Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers, including > various SNMP-related numbers, and specifically, new > IANAItuProbableCause values. Values of > IANAItuProbableCause less than 1024 are reserved for causes > that correspond to ITU probable cause. IANAItuProbableCause > of 0 is reserved for special purposes and therefore cannot > be assigned. See http://www.iana.org" > >With > >" ITU-T probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure syntactic uniqueness. Probable >cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of the enumerations in this TC. > IANAItuProbableCause value of 0 is reserved for special > purposes and MUST NOT be assigned. > > Values of IANAItuProbableCause in the range 1 to 1023 are >reserved > for causes that correspond to ITU-T probable cause. > > All other requests for new causes will be handled on a >first-come, > first served basis and will be assigned enumeration values >starting > with 1025. > > Request should come in the form of well-formed SMI [RFC2578] > for enumeration names that are unique and sufficiently >descriptive. > > While some effort will be taken to ensure that new probable >causes > do not conceptually duplicate existing probable causes it is > acknowledged that the existence of conceptual duplicates in the > starting probable cause list is an known industry reality. > > To aid IANA in the administration of probable cause names and >values, > the OPS Area Director will appoint one or more experts to help >review > requests. > > See http://www.iana.org > > " > >Sharon > >-----Original Message----- >From: Chisholm, Sharon [CAR:0S00:EXCH] >Sent: Tuesday, January 20, 2004 4:45 PM >To: disman@ietf.org >Subject: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 2) > > >Hi > >Here is an updated proposed resolution based on Bert's comments > >----- > >The following is the proposed resolution to IESG-1 and IESG-5 > >In the description for IanaItuProbableCause, replace the description > >"ITU probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure uniqueness. Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers, including > various SNMP-related numbers, and specifically, new > IANAItuProbableCause values. Values of > IANAItuProbableCause less than 1024 are reserved for causes > that correspond to ITU probable cause. IANAItuProbableCause > of 0 is reserved for special purposes and therefore cannot > be assigned. See http://www.iana.org" > >With > >" ITU-T probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure syntactic uniqueness. Probable >cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers. IANAItuProbableCause > of 0 is reserved for special purposes and MUST NOT > be assigned. > > Values of IANAItuProbableCause in the range 1 to 1023 are >reserved > for causes that correspond to ITU-T probable cause. All other >requests > for new causes will be handled on a first-come, first served >basis and > will be assigned enumeration values starting with 1025. Request >should > come in the form of well-formed SMI [RFC2578] for enumeration >names > that are unique and sufficiently descriptive. > > While some effort will be taken to ensure that new probable >causes > do not conceptually duplicate existing probable causes it is > acknowledged that the existence of conceptual duplicates in the > starting probable cause list is an known industry reality. > > To aid IANA in the administration of probable cause names and >values, > the Management Area Director will appoint an expert to help >review > requests. > > See http://www.iana.org > > " > >Sharon Chisholm >Portfolio Integration >Nortel Networks >Ottawa, Canada > > From disman-admin@ietf.org Thu Jan 22 15:44:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10229 for ; Thu, 22 Jan 2004 15:44:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjlgH-0000uU-Bn; Thu, 22 Jan 2004 15:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajlfx-0000tW-LU for disman@optimus.ietf.org; Thu, 22 Jan 2004 15:43:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10119 for ; Thu, 22 Jan 2004 15:43:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajlfw-0007nX-00 for disman@ietf.org; Thu, 22 Jan 2004 15:43:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajlem-0007cH-00 for disman@ietf.org; Thu, 22 Jan 2004 15:42:29 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Ajldq-0007O8-00 for disman@ietf.org; Thu, 22 Jan 2004 15:41:30 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0MKewv27464 for ; Thu, 22 Jan 2004 15:40:58 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Jan 2004 15:40:58 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409E906B2@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Jan 2004 15:40:50 -0500 Hi While I sending this email, I'm just going to add that I think we are all happy with the issues raised as part of the IESG review so I'm going to go ahead and issue the update. I event type is fairly straight forward and the IESG did not raise any specific issues with it, so I think it's fine as is. To answer your other questions, 1024 is the other for the entire list. I think this is the de factor interpretation of this type of enumeration. I think the typo in 3 was already raised, but I'll be make sure it gets fixed up. Thanks, Sharon -----Original Message----- From: tom petch [mailto:enginet@dial.pipex.com] Sent: Thursday, January 22, 2004 1:01 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; disman@ietf.org Subject: Re: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) Sharon no problems with the new text but :-) 1) where does 1024(other) sit in this? is it other for the whole range, other for 1 to1023, other for 1025 - nnnn? 2) is there a similar issue with IANAItuEventType do we need a similar expanded description for that? 3) the IANAItuEventType ::= TEXTUAL-CONVENTION has in its description The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAEventType values. See http://www.iana.org " I think an Itu has got lost from there. 4) I never have understood the X733 appendage; what is the duplication between which two (or more) lists where? I assume the whole list is present in X.733 as well as in this document so where else? Tom Petch nwnetworks@dial.pipex.com -----Original Message----- From: Sharon Chisholm To: disman@ietf.org Date: 21 January 2004 20:37 Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) >Hi > >Based on some further suggestions from Bert, here is the latest >proposal. > >---- >The following is the proposed resolution to IESG-1 and IESG-5 > >In the description for IanaItuProbableCause, replace the description > >"ITU probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure uniqueness. Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers, including > various SNMP-related numbers, and specifically, new > IANAItuProbableCause values. Values of > IANAItuProbableCause less than 1024 are reserved for causes > that correspond to ITU probable cause. IANAItuProbableCause > of 0 is reserved for special purposes and therefore cannot > be assigned. See http://www.iana.org" > >With > >" ITU-T probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure syntactic uniqueness. >Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of the enumerations in this TC. > IANAItuProbableCause value of 0 is reserved for special > purposes and MUST NOT be assigned. > > Values of IANAItuProbableCause in the range 1 to 1023 are >reserved > for causes that correspond to ITU-T probable cause. > > All other requests for new causes will be handled on a >first-come, > first served basis and will be assigned enumeration values >starting > with 1025. > > Request should come in the form of well-formed SMI [RFC2578] > for enumeration names that are unique and sufficiently >descriptive. > > While some effort will be taken to ensure that new probable >causes > do not conceptually duplicate existing probable causes it is > acknowledged that the existence of conceptual duplicates in the > starting probable cause list is an known industry reality. > > To aid IANA in the administration of probable cause names >and values, > the OPS Area Director will appoint one or more experts to >help review > requests. > > See http://www.iana.org > > " > >Sharon > >-----Original Message----- >From: Chisholm, Sharon [CAR:0S00:EXCH] >Sent: Tuesday, January 20, 2004 4:45 PM >To: disman@ietf.org >Subject: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 2) > > >Hi > >Here is an updated proposed resolution based on Bert's comments > >----- > >The following is the proposed resolution to IESG-1 and IESG-5 > >In the description for IanaItuProbableCause, replace the description > >"ITU probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure uniqueness. Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers, including > various SNMP-related numbers, and specifically, new > IANAItuProbableCause values. Values of > IANAItuProbableCause less than 1024 are reserved for causes > that correspond to ITU probable cause. IANAItuProbableCause > of 0 is reserved for special purposes and therefore cannot > be assigned. See http://www.iana.org" > >With > >" ITU-T probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure syntactic uniqueness. >Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers. IANAItuProbableCause > of 0 is reserved for special purposes and MUST NOT > be assigned. > > Values of IANAItuProbableCause in the range 1 to 1023 are >reserved > for causes that correspond to ITU-T probable cause. All >other requests > for new causes will be handled on a first-come, first served >basis and > will be assigned enumeration values starting with 1025. >Request should > come in the form of well-formed SMI [RFC2578] for >enumeration names > that are unique and sufficiently descriptive. > > While some effort will be taken to ensure that new probable >causes > do not conceptually duplicate existing probable causes it is > acknowledged that the existence of conceptual duplicates in the > starting probable cause list is an known industry reality. > > To aid IANA in the administration of probable cause names >and values, > the Management Area Director will appoint an expert to help >review > requests. > > See http://www.iana.org > > " > >Sharon Chisholm >Portfolio Integration >Nortel Networks >Ottawa, Canada > > From exim@www1.ietf.org Thu Jan 22 15:47:02 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10497 for ; Thu, 22 Jan 2004 15:47:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajlij-00014l-Qz for disman-archive@odin.ietf.org; Thu, 22 Jan 2004 15:46:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MKkXgl004131 for disman-archive@odin.ietf.org; Thu, 22 Jan 2004 15:46:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajlij-00014Y-Nw for disman-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 15:46:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10487 for ; Thu, 22 Jan 2004 15:46:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajlih-0000Pu-00 for disman-web-archive@ietf.org; Thu, 22 Jan 2004 15:46:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajlhf-0000GZ-00 for disman-web-archive@ietf.org; Thu, 22 Jan 2004 15:45:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjlgR-000030-00 for disman-web-archive@ietf.org; Thu, 22 Jan 2004 15:44:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjlgH-0000uU-Bn; Thu, 22 Jan 2004 15:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajlfx-0000tW-LU for disman@optimus.ietf.org; Thu, 22 Jan 2004 15:43:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10119 for ; Thu, 22 Jan 2004 15:43:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajlfw-0007nX-00 for disman@ietf.org; Thu, 22 Jan 2004 15:43:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajlem-0007cH-00 for disman@ietf.org; Thu, 22 Jan 2004 15:42:29 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Ajldq-0007O8-00 for disman@ietf.org; Thu, 22 Jan 2004 15:41:30 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0MKewv27464 for ; Thu, 22 Jan 2004 15:40:58 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Jan 2004 15:40:58 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409E906B2@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Jan 2004 15:40:50 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi While I sending this email, I'm just going to add that I think we are all happy with the issues raised as part of the IESG review so I'm going to go ahead and issue the update. I event type is fairly straight forward and the IESG did not raise any specific issues with it, so I think it's fine as is. To answer your other questions, 1024 is the other for the entire list. I think this is the de factor interpretation of this type of enumeration. I think the typo in 3 was already raised, but I'll be make sure it gets fixed up. Thanks, Sharon -----Original Message----- From: tom petch [mailto:enginet@dial.pipex.com] Sent: Thursday, January 22, 2004 1:01 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; disman@ietf.org Subject: Re: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) Sharon no problems with the new text but :-) 1) where does 1024(other) sit in this? is it other for the whole range, other for 1 to1023, other for 1025 - nnnn? 2) is there a similar issue with IANAItuEventType do we need a similar expanded description for that? 3) the IANAItuEventType ::= TEXTUAL-CONVENTION has in its description The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAEventType values. See http://www.iana.org " I think an Itu has got lost from there. 4) I never have understood the X733 appendage; what is the duplication between which two (or more) lists where? I assume the whole list is present in X.733 as well as in this document so where else? Tom Petch nwnetworks@dial.pipex.com -----Original Message----- From: Sharon Chisholm To: disman@ietf.org Date: 21 January 2004 20:37 Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) >Hi > >Based on some further suggestions from Bert, here is the latest >proposal. > >---- >The following is the proposed resolution to IESG-1 and IESG-5 > >In the description for IanaItuProbableCause, replace the description > >"ITU probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure uniqueness. Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers, including > various SNMP-related numbers, and specifically, new > IANAItuProbableCause values. Values of > IANAItuProbableCause less than 1024 are reserved for causes > that correspond to ITU probable cause. IANAItuProbableCause > of 0 is reserved for special purposes and therefore cannot > be assigned. See http://www.iana.org" > >With > >" ITU-T probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure syntactic uniqueness. >Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of the enumerations in this TC. > IANAItuProbableCause value of 0 is reserved for special > purposes and MUST NOT be assigned. > > Values of IANAItuProbableCause in the range 1 to 1023 are >reserved > for causes that correspond to ITU-T probable cause. > > All other requests for new causes will be handled on a >first-come, > first served basis and will be assigned enumeration values >starting > with 1025. > > Request should come in the form of well-formed SMI [RFC2578] > for enumeration names that are unique and sufficiently >descriptive. > > While some effort will be taken to ensure that new probable >causes > do not conceptually duplicate existing probable causes it is > acknowledged that the existence of conceptual duplicates in the > starting probable cause list is an known industry reality. > > To aid IANA in the administration of probable cause names >and values, > the OPS Area Director will appoint one or more experts to >help review > requests. > > See http://www.iana.org > > " > >Sharon > >-----Original Message----- >From: Chisholm, Sharon [CAR:0S00:EXCH] >Sent: Tuesday, January 20, 2004 4:45 PM >To: disman@ietf.org >Subject: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 2) > > >Hi > >Here is an updated proposed resolution based on Bert's comments > >----- > >The following is the proposed resolution to IESG-1 and IESG-5 > >In the description for IanaItuProbableCause, replace the description > >"ITU probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure uniqueness. Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers, including > various SNMP-related numbers, and specifically, new > IANAItuProbableCause values. Values of > IANAItuProbableCause less than 1024 are reserved for causes > that correspond to ITU probable cause. IANAItuProbableCause > of 0 is reserved for special purposes and therefore cannot > be assigned. See http://www.iana.org" > >With > >" ITU-T probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure syntactic uniqueness. >Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers. IANAItuProbableCause > of 0 is reserved for special purposes and MUST NOT > be assigned. > > Values of IANAItuProbableCause in the range 1 to 1023 are >reserved > for causes that correspond to ITU-T probable cause. All >other requests > for new causes will be handled on a first-come, first served >basis and > will be assigned enumeration values starting with 1025. >Request should > come in the form of well-formed SMI [RFC2578] for >enumeration names > that are unique and sufficiently descriptive. > > While some effort will be taken to ensure that new probable >causes > do not conceptually duplicate existing probable causes it is > acknowledged that the existence of conceptual duplicates in the > starting probable cause list is an known industry reality. > > To aid IANA in the administration of probable cause names >and values, > the Management Area Director will appoint an expert to help >review > requests. > > See http://www.iana.org > > " > >Sharon Chisholm >Portfolio Integration >Nortel Networks >Ottawa, Canada > > From disman-admin@ietf.org Thu Jan 22 16:05:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11496 for ; Thu, 22 Jan 2004 16:05:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajm0c-0001xx-U2; Thu, 22 Jan 2004 16:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajm04-0001xF-Oh for disman@optimus.ietf.org; Thu, 22 Jan 2004 16:04:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11464 for ; Thu, 22 Jan 2004 16:04:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajlzt-0001PU-00 for disman@ietf.org; Thu, 22 Jan 2004 16:04:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjlwP-0001Kf-00 for disman@ietf.org; Thu, 22 Jan 2004 16:00:43 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AjluO-0001F0-00 for disman@ietf.org; Thu, 22 Jan 2004 15:58:36 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0MKw4W00420 for ; Thu, 22 Jan 2004 15:58:04 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Jan 2004 15:58:04 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409E906F7@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Jan 2004 15:58:03 -0500 Hi That would be the proposed resolution to the issues ... I don't think I can blame that one on my keyboard, which hasn't quite recovered from its close encounter with a Diet Coke this morning ... Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Thursday, January 22, 2004 3:41 PM To: disman@ietf.org Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) Hi While I sending this email, I'm just going to add that I think we are all happy with the issues raised as part of the IESG review so I'm going to go ahead and issue the update. I event type is fairly straight forward and the IESG did not raise any specific issues with it, so I think it's fine as is. To answer your other questions, 1024 is the other for the entire list. I think this is the de factor interpretation of this type of enumeration. I think the typo in 3 was already raised, but I'll be make sure it gets fixed up. Thanks, Sharon -----Original Message----- From: tom petch [mailto:enginet@dial.pipex.com] Sent: Thursday, January 22, 2004 1:01 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; disman@ietf.org Subject: Re: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) Sharon no problems with the new text but :-) 1) where does 1024(other) sit in this? is it other for the whole range, other for 1 to1023, other for 1025 - nnnn? 2) is there a similar issue with IANAItuEventType do we need a similar expanded description for that? 3) the IANAItuEventType ::= TEXTUAL-CONVENTION has in its description The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAEventType values. See http://www.iana.org " I think an Itu has got lost from there. 4) I never have understood the X733 appendage; what is the duplication between which two (or more) lists where? I assume the whole list is present in X.733 as well as in this document so where else? Tom Petch nwnetworks@dial.pipex.com -----Original Message----- From: Sharon Chisholm To: disman@ietf.org Date: 21 January 2004 20:37 Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) >Hi > >Based on some further suggestions from Bert, here is the latest >proposal. > >---- >The following is the proposed resolution to IESG-1 and IESG-5 > >In the description for IanaItuProbableCause, replace the description > >"ITU probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure uniqueness. Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers, including > various SNMP-related numbers, and specifically, new > IANAItuProbableCause values. Values of > IANAItuProbableCause less than 1024 are reserved for causes > that correspond to ITU probable cause. IANAItuProbableCause > of 0 is reserved for special purposes and therefore cannot > be assigned. See http://www.iana.org" > >With > >" ITU-T probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure syntactic uniqueness. >Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of the enumerations in this TC. > IANAItuProbableCause value of 0 is reserved for special > purposes and MUST NOT be assigned. > > Values of IANAItuProbableCause in the range 1 to 1023 are >reserved > for causes that correspond to ITU-T probable cause. > > All other requests for new causes will be handled on a >first-come, > first served basis and will be assigned enumeration values >starting > with 1025. > > Request should come in the form of well-formed SMI [RFC2578] > for enumeration names that are unique and sufficiently >descriptive. > > While some effort will be taken to ensure that new probable >causes > do not conceptually duplicate existing probable causes it is > acknowledged that the existence of conceptual duplicates in the > starting probable cause list is an known industry reality. > > To aid IANA in the administration of probable cause names >and values, > the OPS Area Director will appoint one or more experts to >help review > requests. > > See http://www.iana.org > > " > >Sharon > >-----Original Message----- >From: Chisholm, Sharon [CAR:0S00:EXCH] >Sent: Tuesday, January 20, 2004 4:45 PM >To: disman@ietf.org >Subject: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 2) > > >Hi > >Here is an updated proposed resolution based on Bert's comments > >----- > >The following is the proposed resolution to IESG-1 and IESG-5 > >In the description for IanaItuProbableCause, replace the description > >"ITU probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure uniqueness. Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers, including > various SNMP-related numbers, and specifically, new > IANAItuProbableCause values. Values of > IANAItuProbableCause less than 1024 are reserved for causes > that correspond to ITU probable cause. IANAItuProbableCause > of 0 is reserved for special purposes and therefore cannot > be assigned. See http://www.iana.org" > >With > >" ITU-T probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure syntactic uniqueness. >Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers. IANAItuProbableCause > of 0 is reserved for special purposes and MUST NOT > be assigned. > > Values of IANAItuProbableCause in the range 1 to 1023 are >reserved > for causes that correspond to ITU-T probable cause. All >other requests > for new causes will be handled on a first-come, first served >basis and > will be assigned enumeration values starting with 1025. >Request should > come in the form of well-formed SMI [RFC2578] for >enumeration names > that are unique and sufficiently descriptive. > > While some effort will be taken to ensure that new probable >causes > do not conceptually duplicate existing probable causes it is > acknowledged that the existence of conceptual duplicates in the > starting probable cause list is an known industry reality. > > To aid IANA in the administration of probable cause names >and values, > the Management Area Director will appoint an expert to help >review > requests. > > See http://www.iana.org > > " > >Sharon Chisholm >Portfolio Integration >Nortel Networks >Ottawa, Canada > > From exim@www1.ietf.org Thu Jan 22 16:16:02 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11637 for ; Thu, 22 Jan 2004 16:16:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjmAo-00033G-NV for disman-archive@odin.ietf.org; Thu, 22 Jan 2004 16:15:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MLFY4E011727 for disman-archive@odin.ietf.org; Thu, 22 Jan 2004 16:15:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjmAo-000334-Hv for disman-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 16:15:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11623 for ; Thu, 22 Jan 2004 16:15:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjmAc-0002FI-00 for disman-web-archive@ietf.org; Thu, 22 Jan 2004 16:15:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajm68-0001io-00 for disman-web-archive@ietf.org; Thu, 22 Jan 2004 16:10:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajm0y-0001U5-00 for disman-web-archive@ietf.org; Thu, 22 Jan 2004 16:05:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajm0c-0001xx-U2; Thu, 22 Jan 2004 16:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajm04-0001xF-Oh for disman@optimus.ietf.org; Thu, 22 Jan 2004 16:04:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11464 for ; Thu, 22 Jan 2004 16:04:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajlzt-0001PU-00 for disman@ietf.org; Thu, 22 Jan 2004 16:04:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjlwP-0001Kf-00 for disman@ietf.org; Thu, 22 Jan 2004 16:00:43 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AjluO-0001F0-00 for disman@ietf.org; Thu, 22 Jan 2004 15:58:36 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0MKw4W00420 for ; Thu, 22 Jan 2004 15:58:04 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Jan 2004 15:58:04 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409E906F7@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Jan 2004 15:58:03 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi That would be the proposed resolution to the issues ... I don't think I can blame that one on my keyboard, which hasn't quite recovered from its close encounter with a Diet Coke this morning ... Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Thursday, January 22, 2004 3:41 PM To: disman@ietf.org Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) Hi While I sending this email, I'm just going to add that I think we are all happy with the issues raised as part of the IESG review so I'm going to go ahead and issue the update. I event type is fairly straight forward and the IESG did not raise any specific issues with it, so I think it's fine as is. To answer your other questions, 1024 is the other for the entire list. I think this is the de factor interpretation of this type of enumeration. I think the typo in 3 was already raised, but I'll be make sure it gets fixed up. Thanks, Sharon -----Original Message----- From: tom petch [mailto:enginet@dial.pipex.com] Sent: Thursday, January 22, 2004 1:01 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; disman@ietf.org Subject: Re: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) Sharon no problems with the new text but :-) 1) where does 1024(other) sit in this? is it other for the whole range, other for 1 to1023, other for 1025 - nnnn? 2) is there a similar issue with IANAItuEventType do we need a similar expanded description for that? 3) the IANAItuEventType ::= TEXTUAL-CONVENTION has in its description The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new IANAEventType values. See http://www.iana.org " I think an Itu has got lost from there. 4) I never have understood the X733 appendage; what is the duplication between which two (or more) lists where? I assume the whole list is present in X.733 as well as in this document so where else? Tom Petch nwnetworks@dial.pipex.com -----Original Message----- From: Sharon Chisholm To: disman@ietf.org Date: 21 January 2004 20:37 Subject: RE: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 3) >Hi > >Based on some further suggestions from Bert, here is the latest >proposal. > >---- >The following is the proposed resolution to IESG-1 and IESG-5 > >In the description for IanaItuProbableCause, replace the description > >"ITU probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure uniqueness. Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers, including > various SNMP-related numbers, and specifically, new > IANAItuProbableCause values. Values of > IANAItuProbableCause less than 1024 are reserved for causes > that correspond to ITU probable cause. IANAItuProbableCause > of 0 is reserved for special purposes and therefore cannot > be assigned. See http://www.iana.org" > >With > >" ITU-T probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure syntactic uniqueness. >Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of the enumerations in this TC. > IANAItuProbableCause value of 0 is reserved for special > purposes and MUST NOT be assigned. > > Values of IANAItuProbableCause in the range 1 to 1023 are >reserved > for causes that correspond to ITU-T probable cause. > > All other requests for new causes will be handled on a >first-come, > first served basis and will be assigned enumeration values >starting > with 1025. > > Request should come in the form of well-formed SMI [RFC2578] > for enumeration names that are unique and sufficiently >descriptive. > > While some effort will be taken to ensure that new probable >causes > do not conceptually duplicate existing probable causes it is > acknowledged that the existence of conceptual duplicates in the > starting probable cause list is an known industry reality. > > To aid IANA in the administration of probable cause names >and values, > the OPS Area Director will appoint one or more experts to >help review > requests. > > See http://www.iana.org > > " > >Sharon > >-----Original Message----- >From: Chisholm, Sharon [CAR:0S00:EXCH] >Sent: Tuesday, January 20, 2004 4:45 PM >To: disman@ietf.org >Subject: [Disman] Propose Resolution to iesg-1 and iesg-5 (take 2) > > >Hi > >Here is an updated proposed resolution based on Bert's comments > >----- > >The following is the proposed resolution to IESG-1 and IESG-5 > >In the description for IanaItuProbableCause, replace the description > >"ITU probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure uniqueness. Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers, including > various SNMP-related numbers, and specifically, new > IANAItuProbableCause values. Values of > IANAItuProbableCause less than 1024 are reserved for causes > that correspond to ITU probable cause. IANAItuProbableCause > of 0 is reserved for special purposes and therefore cannot > be assigned. See http://www.iana.org" > >With > >" ITU-T probable cause values. Duplicate values defined in X.733 > are appended with X733 to ensure syntactic uniqueness. >Probable cause > value 0 is reserved for special purposes. > > The Internet Assigned Number Authority (IANA) is responsible > for the assignment of all Internet numbers. IANAItuProbableCause > of 0 is reserved for special purposes and MUST NOT > be assigned. > > Values of IANAItuProbableCause in the range 1 to 1023 are >reserved > for causes that correspond to ITU-T probable cause. All >other requests > for new causes will be handled on a first-come, first served >basis and > will be assigned enumeration values starting with 1025. >Request should > come in the form of well-formed SMI [RFC2578] for >enumeration names > that are unique and sufficiently descriptive. > > While some effort will be taken to ensure that new probable >causes > do not conceptually duplicate existing probable causes it is > acknowledged that the existence of conceptual duplicates in the > starting probable cause list is an known industry reality. > > To aid IANA in the administration of probable cause names >and values, > the Management Area Director will appoint an expert to help >review > requests. > > See http://www.iana.org > > " > >Sharon Chisholm >Portfolio Integration >Nortel Networks >Ottawa, Canada > > From disman-admin@ietf.org Sun Jan 25 06:40:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28720 for ; Sun, 25 Jan 2004 06:40:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkicW-0004vx-2u; Sun, 25 Jan 2004 06:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Akibb-0004v3-WB for disman@optimus.ietf.org; Sun, 25 Jan 2004 06:39:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28698 for ; Sun, 25 Jan 2004 06:39:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkibX-0006rx-00 for disman@ietf.org; Sun, 25 Jan 2004 06:39:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Akiae-0006ql-00 for disman@ietf.org; Sun, 25 Jan 2004 06:38:08 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AkiaL-0006p3-00 for disman@ietf.org; Sun, 25 Jan 2004 06:37:49 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0PBbEkC001321 for ; Sun, 25 Jan 2004 12:37:15 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0PBbAIx001319 for ; Sun, 25 Jan 2004 12:37:10 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0PBb9kA001316; Sun, 25 Jan 2004 12:37:10 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E3B83FC178; Sun, 25 Jan 2004 12:37:06 +0100 (CET) From: Juergen Quittek To: Juergen Schoenwaelder Cc: disman@ietf.org Subject: Re: [Disman] traceroute-mib-1 Message-ID: <2147483647.1075034234@[10.1.1.26]> In-Reply-To: <200401221240.i0MCeC3b016637@hansa.ibr.cs.tu-bs.de> References: <2147483647.1074703989@[10.1.1.171]> <200401211637.i0LGbTQE001180@hansa.ibr.cs.tu-bs.de> <2147483647.1074732470@[10.1.1.26]> <200401221240.i0MCeC3b016637@hansa.ibr.cs.tu-bs.de> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 25 Jan 2004 12:37:15 +0100 Content-Transfer-Encoding: 7bit --On 22.01.2004 13:40 h +0100 Juergen Schoenwaelder wrote: > >>>>>> Juergen Quittek writes: > > Juergen> Wouldn't a good path be a path for which responses were > Juergen> received from all hops? > > Sure, in theory. But in reality, there are hops in the path which will > simply not respond. So a good path is a path for which responses or > timeouts have been received for all hops. > > (And again, if you hit an unfriendly firewall somewhere on the path, > you might end up increasing the ttl until you reach the max. ttl > value.) Of course. Would this also be a good path? I guess: yes. Still we need to clarify this in the DESCRIPTION clause. So here is another try: traceRouteResultsLastGoodPath OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when the last complete path was determined. A path is complete if responses were received or timeout occurred for each hop on the path, i.e. for each TTL value from the value of the corresponding traceRouteCtlInitialTtl object up to the end of the path or - if no reply from the target IP address was received - up to the value of the corresponding traceRouteCtlMaxTtl object." ::= { traceRouteResultsEntry 8 } This is not really nice phrasing. Does anyone have a better suggestion? 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 > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany From exim@www1.ietf.org Sun Jan 25 06:42:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28812 for ; Sun, 25 Jan 2004 06:42:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkieV-00051g-8Y for disman-archive@odin.ietf.org; Sun, 25 Jan 2004 06:42:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0PBg7wY019316 for disman-archive@odin.ietf.org; Sun, 25 Jan 2004 06:42:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkieV-00051T-4n for disman-web-archive@optimus.ietf.org; Sun, 25 Jan 2004 06:42:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28805 for ; Sun, 25 Jan 2004 06:42:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkieR-0006xt-00 for disman-web-archive@ietf.org; Sun, 25 Jan 2004 06:42:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkidT-0006vE-00 for disman-web-archive@ietf.org; Sun, 25 Jan 2004 06:41:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkicV-0006tV-00 for disman-web-archive@ietf.org; Sun, 25 Jan 2004 06:40:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkicW-0004vx-2u; Sun, 25 Jan 2004 06:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Akibb-0004v3-WB for disman@optimus.ietf.org; Sun, 25 Jan 2004 06:39:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28698 for ; Sun, 25 Jan 2004 06:39:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkibX-0006rx-00 for disman@ietf.org; Sun, 25 Jan 2004 06:39:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Akiae-0006ql-00 for disman@ietf.org; Sun, 25 Jan 2004 06:38:08 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AkiaL-0006p3-00 for disman@ietf.org; Sun, 25 Jan 2004 06:37:49 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0PBbEkC001321 for ; Sun, 25 Jan 2004 12:37:15 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0PBbAIx001319 for ; Sun, 25 Jan 2004 12:37:10 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0PBb9kA001316; Sun, 25 Jan 2004 12:37:10 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E3B83FC178; Sun, 25 Jan 2004 12:37:06 +0100 (CET) From: Juergen Quittek To: Juergen Schoenwaelder Cc: disman@ietf.org Subject: Re: [Disman] traceroute-mib-1 Message-ID: <2147483647.1075034234@[10.1.1.26]> In-Reply-To: <200401221240.i0MCeC3b016637@hansa.ibr.cs.tu-bs.de> References: <2147483647.1074703989@[10.1.1.171]> <200401211637.i0LGbTQE001180@hansa.ibr.cs.tu-bs.de> <2147483647.1074732470@[10.1.1.26]> <200401221240.i0MCeC3b016637@hansa.ibr.cs.tu-bs.de> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 25 Jan 2004 12:37:15 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On 22.01.2004 13:40 h +0100 Juergen Schoenwaelder wrote: > >>>>>> Juergen Quittek writes: > > Juergen> Wouldn't a good path be a path for which responses were > Juergen> received from all hops? > > Sure, in theory. But in reality, there are hops in the path which will > simply not respond. So a good path is a path for which responses or > timeouts have been received for all hops. > > (And again, if you hit an unfriendly firewall somewhere on the path, > you might end up increasing the ttl until you reach the max. ttl > value.) Of course. Would this also be a good path? I guess: yes. Still we need to clarify this in the DESCRIPTION clause. So here is another try: traceRouteResultsLastGoodPath OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time when the last complete path was determined. A path is complete if responses were received or timeout occurred for each hop on the path, i.e. for each TTL value from the value of the corresponding traceRouteCtlInitialTtl object up to the end of the path or - if no reply from the target IP address was received - up to the value of the corresponding traceRouteCtlMaxTtl object." ::= { traceRouteResultsEntry 8 } This is not really nice phrasing. Does anyone have a better suggestion? 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 > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany From disman-admin@ietf.org Sun Jan 25 06:54:27 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29246 for ; Sun, 25 Jan 2004 06:54:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Akiq0-0005Xn-T0; Sun, 25 Jan 2004 06:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkipA-0005WK-2M for disman@optimus.ietf.org; Sun, 25 Jan 2004 06:53:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29172 for ; Sun, 25 Jan 2004 06:53:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Akip5-0007UN-00 for disman@ietf.org; Sun, 25 Jan 2004 06:53:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkioB-0007Qj-00 for disman@ietf.org; Sun, 25 Jan 2004 06:52:08 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AkinE-0007LC-00 for disman@ietf.org; Sun, 25 Jan 2004 06:51:08 -0500 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0PBodkA001418 for ; Sun, 25 Jan 2004 12:50:39 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 3A15CFD1E6 for ; Sun, 25 Jan 2004 12:50:37 +0100 (CET) From: Juergen Quittek To: disman@ietf.org Message-ID: <2147483647.1075035045@[10.1.1.26]> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Disman] traceroute-mib-2 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 25 Jan 2004 12:50:45 +0100 Content-Transfer-Encoding: 7bit Dear all, The DISMAN-TRACEROUTE-MIB defines the initial TTL value for a traceroute operations as traceRouteCtlInitialTtl OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object specifies the initial TTL value to use. This enables bypassing the initial (often well known) portion of a path." DEFVAL { 1 } ::= { traceRouteCtlEntry 18 } The range of this object is (0..255). I don't see how a value of 0 would make any sense. Therefore I suggest to change the SYNTAX clause to SYNTAX Unsigned32 (1..255) Any comments? 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 From exim@www1.ietf.org Sun Jan 25 06:55:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29289 for ; Sun, 25 Jan 2004 06:55:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkirE-0005ck-47 for disman-archive@odin.ietf.org; Sun, 25 Jan 2004 06:55:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0PBtGCu021612 for disman-archive@odin.ietf.org; Sun, 25 Jan 2004 06:55:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkirE-0005cV-0M for disman-web-archive@optimus.ietf.org; Sun, 25 Jan 2004 06:55:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29277 for ; Sun, 25 Jan 2004 06:55:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Akir9-0007b4-00 for disman-web-archive@ietf.org; Sun, 25 Jan 2004 06:55:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Akiq9-0007YI-00 for disman-web-archive@ietf.org; Sun, 25 Jan 2004 06:54:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Akipx-0007W7-00 for disman-web-archive@ietf.org; Sun, 25 Jan 2004 06:53:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Akiq0-0005Xn-T0; Sun, 25 Jan 2004 06:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkipA-0005WK-2M for disman@optimus.ietf.org; Sun, 25 Jan 2004 06:53:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29172 for ; Sun, 25 Jan 2004 06:53:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Akip5-0007UN-00 for disman@ietf.org; Sun, 25 Jan 2004 06:53:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkioB-0007Qj-00 for disman@ietf.org; Sun, 25 Jan 2004 06:52:08 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AkinE-0007LC-00 for disman@ietf.org; Sun, 25 Jan 2004 06:51:08 -0500 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0PBodkA001418 for ; Sun, 25 Jan 2004 12:50:39 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 3A15CFD1E6 for ; Sun, 25 Jan 2004 12:50:37 +0100 (CET) From: Juergen Quittek To: disman@ietf.org Message-ID: <2147483647.1075035045@[10.1.1.26]> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Disman] traceroute-mib-2 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 25 Jan 2004 12:50:45 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, The DISMAN-TRACEROUTE-MIB defines the initial TTL value for a traceroute operations as traceRouteCtlInitialTtl OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object specifies the initial TTL value to use. This enables bypassing the initial (often well known) portion of a path." DEFVAL { 1 } ::= { traceRouteCtlEntry 18 } The range of this object is (0..255). I don't see how a value of 0 would make any sense. Therefore I suggest to change the SYNTAX clause to SYNTAX Unsigned32 (1..255) Any comments? 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 From disman-admin@ietf.org Wed Jan 28 08:34:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00386 for ; Wed, 28 Jan 2004 08:34:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlppR-0006JY-MI; Wed, 28 Jan 2004 08:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlnlF-0005Ys-Cu for disman@optimus.ietf.org; Wed, 28 Jan 2004 06:21:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25706 for ; Wed, 28 Jan 2004 06:21:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlnlB-0005r0-00 for disman@ietf.org; Wed, 28 Jan 2004 06:21:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlnkC-0005mk-00 for disman@ietf.org; Wed, 28 Jan 2004 06:20:28 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Alnjq-0005if-00 for disman@ietf.org; Wed, 28 Jan 2004 06:20:06 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0SBJZNA098511 for ; Wed, 28 Jan 2004 12:19:36 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0SBElqd098189 for ; Wed, 28 Jan 2004 12:14:47 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0SBEkN8098184; Wed, 28 Jan 2004 12:14:47 +0100 (CET) Received: from netlab.nec.de (nunzi.office [10.1.1.124]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1CF86FEAA8; Wed, 28 Jan 2004 12:14:46 +0100 (CET) Message-ID: <401799AA.3050808@netlab.nec.de> From: Giorgio Nunzi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en, it MIME-Version: 1.0 To: disman@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Disman] traceroute-mib-5, ping-mib-4, lookup-2 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Jan 2004 12:14:50 +0100 Content-Transfer-Encoding: 7bit Dear all, my last note involves all the three REMOPS MIBs. I describe the traceroute-mib first. traceRouteMaxConcurrentRequests OBJECT-TYPE SYNTAX Unsigned32 UNITS "requests" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of concurrent active traceroute requests that are allowed within an agent implementation. A value of 0 for this object implies that there is no limit for the number of concurrent active requests in effect." DEFVAL { 10 } ::= { traceRouteObjects 1 } An ambiguity holds when a value is set for this object and the agent has already more active requests than the value specified. The solutions possible are: - kill the exceeding requests (for instance the ones started recently) and start them again later; - continue to process them. I suggest the second case and to add the following sentence at the bottom of the DESCRIPTION clause. "The limit applies only to the new rquests being activated. When a new value is set, the agent will process all the requests already active, even if they exceed the limit just imposed." Analogous considerations (and solutions) are valid for the objects pingMaxConcurrentRequests and lookupMaxConcurrentRequests. pingMaxConcurrentRequests OBJECT-TYPE SYNTAX Unsigned32 UNITS "requests" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of concurrent active ping requests that are allowed within an agent implementation. A value of 0 for this object implies that there is no limit for the number of concurrent active requests in effect." DEFVAL { 10 } ::= { pingObjects 1 } lookupMaxConcurrentRequests OBJECT-TYPE SYNTAX Unsigned32 UNITS "requests" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of concurrent active lookup requests that are allowed within an agent implementation. A value of 0 for this object implies that there is no limit for the number of concurrent active requests in effect." DEFVAL { 10 } ::= { lookupObjects 1 } Giorgio -- Giorgio Nunzi Network Laboratories Heidelberg, Germany NEC Europe Ltd. http://www.netlab.nec.de From exim@www1.ietf.org Wed Jan 28 08:36:07 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00547 for ; Wed, 28 Jan 2004 08:36:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alpr1-0006cc-7v for disman-archive@odin.ietf.org; Wed, 28 Jan 2004 08:35:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SDZdIQ025450 for disman-archive@odin.ietf.org; Wed, 28 Jan 2004 08:35:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alpr1-0006cP-4c for disman-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 08:35:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00523 for ; Wed, 28 Jan 2004 08:35:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alpqz-0001hV-00 for disman-web-archive@ietf.org; Wed, 28 Jan 2004 08:35:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alpq4-0001cH-00 for disman-web-archive@ietf.org; Wed, 28 Jan 2004 08:34:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlppU-0001XS-00 for disman-web-archive@ietf.org; Wed, 28 Jan 2004 08:34:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlppR-0006JI-55; Wed, 28 Jan 2004 08:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlnbU-0004UV-Cv for disman@optimus.ietf.org; Wed, 28 Jan 2004 06:11:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25431 for ; Wed, 28 Jan 2004 06:11:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlnbQ-00056Z-00 for disman@ietf.org; Wed, 28 Jan 2004 06:11:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alnac-000537-00 for disman@ietf.org; Wed, 28 Jan 2004 06:10:34 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Alna6-0004zB-00 for disman@ietf.org; Wed, 28 Jan 2004 06:10:02 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0SB9VNA097726 for ; Wed, 28 Jan 2004 12:09:32 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0SB7l4e097376 for ; Wed, 28 Jan 2004 12:07:47 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0SB7lN8097374; Wed, 28 Jan 2004 12:07:47 +0100 (CET) Received: from netlab.nec.de (nunzi.office [10.1.1.124]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 0EB9BFEAD9; Wed, 28 Jan 2004 12:07:47 +0100 (CET) Message-ID: <40179807.9000000@netlab.nec.de> From: Giorgio Nunzi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en, it MIME-Version: 1.0 To: disman@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Disman] ping-mib-2, traceroute-mib-3 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Jan 2004 12:07:51 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, I collected some notes regarding the REMOPS MIBs. I start with two similar remarks for the ping-mib and the traceroute-mib. Looking at the ping-mib, if the value of pingCtlFrequency is different from zero, then the ping tests can be processed forever, dealing to theoretically infinitive values of the objects pingResultsProbeResponses and pingResultsSentProbes. pingCtlFrequency OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds to wait before repeating a ping test as defined by the value of the various objects in the corresponding row. A single ping test consists of a series of ping probes. The number of probes is determined by the value of the corresponding pingCtlProbeCount object. After a single test completes the number of seconds as defined by the value of pingCtlFrequency MUST elapse before the next ping test is started. A value of 0 for this object implies that the test as defined by the corresponding entry will not be repeated." DEFVAL { 0 } ::= { pingCtlEntry 10 } pingResultsProbeResponses OBJECT-TYPE SYNTAX Unsigned32 UNITS "responses" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of responses received for the corresponding pingCtlEntry and pingResultsEntry. The value of this object MUST be reported as 0 when no probe responses have been received." ::= { pingResultsEntry 7 } pingResultsSentProbes OBJECT-TYPE SYNTAX Unsigned32 UNITS "probes" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object reflects the number of probes sent for the corresponding pingCtlEntry and pingResultsEntry. The value of this object MUST be reported as 0 when no probes have been sent." ::= { pingResultsEntry 8 } The values of pingResultsProbeResponses and pingResultsSentProbes are subjected to grow as long as the test is active and the related value of pingCtlFrequency is different from 0, so I suggest to change the SYNTAX clause of both objects to Gauge32. Similarly, in the traceroute-mib the objects traceRouteResultsTestAttempts and traceRouteResultsTestSuccesses should be changed to Gauge32. traceRouteResultsTestAttempts OBJECT-TYPE SYNTAX Unsigned32 UNITS "tests" MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of attempts to determine a path to a target. The value of this object MUST be started at 0." ::= { traceRouteResultsEntry 6 } traceRouteResultsTestSuccesses OBJECT-TYPE SYNTAX Unsigned32 UNITS "tests" MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of attempts to determine a path to a target that have succeeded. The value of this object MUST be reported as 0 when no attempts have succeeded." ::= { traceRouteResultsEntry 7 } Does someone agree? Giorgio -- Giorgio Nunzi Network Laboratories Heidelberg, Germany NEC Europe Ltd. http://www.netlab.nec.de From exim@www1.ietf.org Wed Jan 28 08:36:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00566 for ; Wed, 28 Jan 2004 08:36:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alpr5-0006cx-3Q for disman-archive@odin.ietf.org; Wed, 28 Jan 2004 08:35:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SDZhdC025469 for disman-archive@odin.ietf.org; Wed, 28 Jan 2004 08:35:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alpr5-0006ci-0B for disman-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 08:35:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00530 for ; Wed, 28 Jan 2004 08:35:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alpr3-0001i8-00 for disman-web-archive@ietf.org; Wed, 28 Jan 2004 08:35:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alpq5-0001cY-00 for disman-web-archive@ietf.org; Wed, 28 Jan 2004 08:34:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlppU-0001XT-00 for disman-web-archive@ietf.org; Wed, 28 Jan 2004 08:34:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlppR-0006JQ-De; Wed, 28 Jan 2004 08:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlngK-00051n-Fd for disman@optimus.ietf.org; Wed, 28 Jan 2004 06:16:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25555 for ; Wed, 28 Jan 2004 06:16:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlngG-0005Td-00 for disman@ietf.org; Wed, 28 Jan 2004 06:16:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlnfN-0005Pg-00 for disman@ietf.org; Wed, 28 Jan 2004 06:15:30 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Alnex-0005LZ-00 for disman@ietf.org; Wed, 28 Jan 2004 06:15:04 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0SBEXNA098168 for ; Wed, 28 Jan 2004 12:14:34 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0SBChCe098024 for ; Wed, 28 Jan 2004 12:12:43 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0SBCgN8098022; Wed, 28 Jan 2004 12:12:43 +0100 (CET) Received: from netlab.nec.de (nunzi.office [10.1.1.124]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 60F44FEA86; Wed, 28 Jan 2004 12:12:42 +0100 (CET) Message-ID: <4017992E.1090404@netlab.nec.de> From: Giorgio Nunzi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en, it MIME-Version: 1.0 To: disman@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Disman] ping-mib-3, traceroute-mib-4 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Jan 2004 12:12:46 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, my second note involves again both the ping-mib and traceroute-mib. Refering to the ping-mib, it's not totally clear to me if the object pingResultsOperStatus tells if the ping test has been completed. pingResultsOperStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), -- test is in progress disabled(2) -- test has stopped } MAX-ACCESS read-only STATUS current DESCRIPTION "Reflects the operational state of a pingCtlEntry: enabled(1) - Test is active. disabled(2) - Test has stopped." ::= { pingResultsEntry 1 } If the related value of pingCtlFrequency is 0 and the test is finished, no other tests are scheduled. At this point we cannot say that the 'test is in progress'; on the other hand it's not clear if the value disabled(2) should be set. I suggest two alternatives: - extend the definition of the disabled(2) to include the case when no more tests are scheduled; - add a new value completed(3). I personally find more convenient the second solution to outline that the values of the conceptual row will not change. Analogous considerations are valid concerning the objects traceRouteResultsOperStatus and traceRouteCtlFrequency; the solutions are the same as well. traceRouteResultsOperStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), -- test is in progress disabled(2) -- test has stopped } MAX-ACCESS read-only STATUS current DESCRIPTION "Reflects the operational state of an traceRouteCtlEntry: enabled(1) - Test is active. disabled(2) - Test has stopped." ::= { traceRouteResultsEntry 1 } Please let me know if you find this remark convenient. Giorgio -- Giorgio Nunzi Network Laboratories Heidelberg, Germany NEC Europe Ltd. http://www.netlab.nec.de From exim@www1.ietf.org Wed Jan 28 08:36:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00585 for ; Wed, 28 Jan 2004 08:36:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alpr5-0006dF-Rb for disman-archive@odin.ietf.org; Wed, 28 Jan 2004 08:35:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SDZhP7025487 for disman-archive@odin.ietf.org; Wed, 28 Jan 2004 08:35:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alpr5-0006d0-ON for disman-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 08:35:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00535 for ; Wed, 28 Jan 2004 08:35:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alpr4-0001iD-00 for disman-web-archive@ietf.org; Wed, 28 Jan 2004 08:35:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alpq5-0001cg-00 for disman-web-archive@ietf.org; Wed, 28 Jan 2004 08:34:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlppU-0001XU-00 for disman-web-archive@ietf.org; Wed, 28 Jan 2004 08:34:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlppR-0006JY-MI; Wed, 28 Jan 2004 08:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlnlF-0005Ys-Cu for disman@optimus.ietf.org; Wed, 28 Jan 2004 06:21:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25706 for ; Wed, 28 Jan 2004 06:21:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlnlB-0005r0-00 for disman@ietf.org; Wed, 28 Jan 2004 06:21:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlnkC-0005mk-00 for disman@ietf.org; Wed, 28 Jan 2004 06:20:28 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Alnjq-0005if-00 for disman@ietf.org; Wed, 28 Jan 2004 06:20:06 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0SBJZNA098511 for ; Wed, 28 Jan 2004 12:19:36 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0SBElqd098189 for ; Wed, 28 Jan 2004 12:14:47 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0SBEkN8098184; Wed, 28 Jan 2004 12:14:47 +0100 (CET) Received: from netlab.nec.de (nunzi.office [10.1.1.124]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1CF86FEAA8; Wed, 28 Jan 2004 12:14:46 +0100 (CET) Message-ID: <401799AA.3050808@netlab.nec.de> From: Giorgio Nunzi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en, it MIME-Version: 1.0 To: disman@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Disman] traceroute-mib-5, ping-mib-4, lookup-2 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Jan 2004 12:14:50 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, my last note involves all the three REMOPS MIBs. I describe the traceroute-mib first. traceRouteMaxConcurrentRequests OBJECT-TYPE SYNTAX Unsigned32 UNITS "requests" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of concurrent active traceroute requests that are allowed within an agent implementation. A value of 0 for this object implies that there is no limit for the number of concurrent active requests in effect." DEFVAL { 10 } ::= { traceRouteObjects 1 } An ambiguity holds when a value is set for this object and the agent has already more active requests than the value specified. The solutions possible are: - kill the exceeding requests (for instance the ones started recently) and start them again later; - continue to process them. I suggest the second case and to add the following sentence at the bottom of the DESCRIPTION clause. "The limit applies only to the new rquests being activated. When a new value is set, the agent will process all the requests already active, even if they exceed the limit just imposed." Analogous considerations (and solutions) are valid for the objects pingMaxConcurrentRequests and lookupMaxConcurrentRequests. pingMaxConcurrentRequests OBJECT-TYPE SYNTAX Unsigned32 UNITS "requests" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of concurrent active ping requests that are allowed within an agent implementation. A value of 0 for this object implies that there is no limit for the number of concurrent active requests in effect." DEFVAL { 10 } ::= { pingObjects 1 } lookupMaxConcurrentRequests OBJECT-TYPE SYNTAX Unsigned32 UNITS "requests" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of concurrent active lookup requests that are allowed within an agent implementation. A value of 0 for this object implies that there is no limit for the number of concurrent active requests in effect." DEFVAL { 10 } ::= { lookupObjects 1 } Giorgio -- Giorgio Nunzi Network Laboratories Heidelberg, Germany NEC Europe Ltd. http://www.netlab.nec.de From disman-admin@ietf.org Wed Jan 28 09:22:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00387 for ; Wed, 28 Jan 2004 08:34:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlppR-0006JQ-De; Wed, 28 Jan 2004 08:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlngK-00051n-Fd for disman@optimus.ietf.org; Wed, 28 Jan 2004 06:16:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25555 for ; Wed, 28 Jan 2004 06:16:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlngG-0005Td-00 for disman@ietf.org; Wed, 28 Jan 2004 06:16:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlnfN-0005Pg-00 for disman@ietf.org; Wed, 28 Jan 2004 06:15:30 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Alnex-0005LZ-00 for disman@ietf.org; Wed, 28 Jan 2004 06:15:04 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0SBEXNA098168 for ; Wed, 28 Jan 2004 12:14:34 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0SBChCe098024 for ; Wed, 28 Jan 2004 12:12:43 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0SBCgN8098022; Wed, 28 Jan 2004 12:12:43 +0100 (CET) Received: from netlab.nec.de (nunzi.office [10.1.1.124]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 60F44FEA86; Wed, 28 Jan 2004 12:12:42 +0100 (CET) Message-ID: <4017992E.1090404@netlab.nec.de> From: Giorgio Nunzi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en, it MIME-Version: 1.0 To: disman@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Disman] ping-mib-3, traceroute-mib-4 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Jan 2004 12:12:46 +0100 Content-Transfer-Encoding: 7bit Dear all, my second note involves again both the ping-mib and traceroute-mib. Refering to the ping-mib, it's not totally clear to me if the object pingResultsOperStatus tells if the ping test has been completed. pingResultsOperStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), -- test is in progress disabled(2) -- test has stopped } MAX-ACCESS read-only STATUS current DESCRIPTION "Reflects the operational state of a pingCtlEntry: enabled(1) - Test is active. disabled(2) - Test has stopped." ::= { pingResultsEntry 1 } If the related value of pingCtlFrequency is 0 and the test is finished, no other tests are scheduled. At this point we cannot say that the 'test is in progress'; on the other hand it's not clear if the value disabled(2) should be set. I suggest two alternatives: - extend the definition of the disabled(2) to include the case when no more tests are scheduled; - add a new value completed(3). I personally find more convenient the second solution to outline that the values of the conceptual row will not change. Analogous considerations are valid concerning the objects traceRouteResultsOperStatus and traceRouteCtlFrequency; the solutions are the same as well. traceRouteResultsOperStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), -- test is in progress disabled(2) -- test has stopped } MAX-ACCESS read-only STATUS current DESCRIPTION "Reflects the operational state of an traceRouteCtlEntry: enabled(1) - Test is active. disabled(2) - Test has stopped." ::= { traceRouteResultsEntry 1 } Please let me know if you find this remark convenient. Giorgio -- Giorgio Nunzi Network Laboratories Heidelberg, Germany NEC Europe Ltd. http://www.netlab.nec.de From disman-admin@ietf.org Wed Jan 28 09:22:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00385 for ; Wed, 28 Jan 2004 08:34:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlppR-0006JI-55; Wed, 28 Jan 2004 08:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlnbU-0004UV-Cv for disman@optimus.ietf.org; Wed, 28 Jan 2004 06:11:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25431 for ; Wed, 28 Jan 2004 06:11:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlnbQ-00056Z-00 for disman@ietf.org; Wed, 28 Jan 2004 06:11:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alnac-000537-00 for disman@ietf.org; Wed, 28 Jan 2004 06:10:34 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Alna6-0004zB-00 for disman@ietf.org; Wed, 28 Jan 2004 06:10:02 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0SB9VNA097726 for ; Wed, 28 Jan 2004 12:09:32 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0SB7l4e097376 for ; Wed, 28 Jan 2004 12:07:47 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0SB7lN8097374; Wed, 28 Jan 2004 12:07:47 +0100 (CET) Received: from netlab.nec.de (nunzi.office [10.1.1.124]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 0EB9BFEAD9; Wed, 28 Jan 2004 12:07:47 +0100 (CET) Message-ID: <40179807.9000000@netlab.nec.de> From: Giorgio Nunzi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en, it MIME-Version: 1.0 To: disman@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Disman] ping-mib-2, traceroute-mib-3 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Jan 2004 12:07:51 +0100 Content-Transfer-Encoding: 7bit Dear all, I collected some notes regarding the REMOPS MIBs. I start with two similar remarks for the ping-mib and the traceroute-mib. Looking at the ping-mib, if the value of pingCtlFrequency is different from zero, then the ping tests can be processed forever, dealing to theoretically infinitive values of the objects pingResultsProbeResponses and pingResultsSentProbes. pingCtlFrequency OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds to wait before repeating a ping test as defined by the value of the various objects in the corresponding row. A single ping test consists of a series of ping probes. The number of probes is determined by the value of the corresponding pingCtlProbeCount object. After a single test completes the number of seconds as defined by the value of pingCtlFrequency MUST elapse before the next ping test is started. A value of 0 for this object implies that the test as defined by the corresponding entry will not be repeated." DEFVAL { 0 } ::= { pingCtlEntry 10 } pingResultsProbeResponses OBJECT-TYPE SYNTAX Unsigned32 UNITS "responses" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of responses received for the corresponding pingCtlEntry and pingResultsEntry. The value of this object MUST be reported as 0 when no probe responses have been received." ::= { pingResultsEntry 7 } pingResultsSentProbes OBJECT-TYPE SYNTAX Unsigned32 UNITS "probes" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object reflects the number of probes sent for the corresponding pingCtlEntry and pingResultsEntry. The value of this object MUST be reported as 0 when no probes have been sent." ::= { pingResultsEntry 8 } The values of pingResultsProbeResponses and pingResultsSentProbes are subjected to grow as long as the test is active and the related value of pingCtlFrequency is different from 0, so I suggest to change the SYNTAX clause of both objects to Gauge32. Similarly, in the traceroute-mib the objects traceRouteResultsTestAttempts and traceRouteResultsTestSuccesses should be changed to Gauge32. traceRouteResultsTestAttempts OBJECT-TYPE SYNTAX Unsigned32 UNITS "tests" MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of attempts to determine a path to a target. The value of this object MUST be started at 0." ::= { traceRouteResultsEntry 6 } traceRouteResultsTestSuccesses OBJECT-TYPE SYNTAX Unsigned32 UNITS "tests" MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of attempts to determine a path to a target that have succeeded. The value of this object MUST be reported as 0 when no attempts have succeeded." ::= { traceRouteResultsEntry 7 } Does someone agree? Giorgio -- Giorgio Nunzi Network Laboratories Heidelberg, Germany NEC Europe Ltd. http://www.netlab.nec.de