From mailman-admin@ietf.org Thu Apr 1 18:14:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07592 for ; Thu, 1 Apr 2004 18:14:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99UT-0006xB-2A for disman-archive@lists.ietf.org; Thu, 01 Apr 2004 16:12:45 -0500 Date: Thu, 01 Apr 2004 11:20:32 -0500 Message-ID: <20040401162032.11029.55676.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: disman-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, disman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for disman-archive@lists.ietf.org: List Password // URL ---- -------- disman@ietf.org hixour https://www1.ietf.org/mailman/options/disman/disman-archive%40lists.ietf.org From exim@www1.ietf.org Thu Apr 1 23:58:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08956 for ; Thu, 1 Apr 2004 23:58: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 1B9Dyv-0000gQ-O1 for disman-archive@odin.ietf.org; Thu, 01 Apr 2004 21:00:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3220ThP002621 for disman-archive@odin.ietf.org; Thu, 1 Apr 2004 21:00:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9BCi-00052P-T5 for disman-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 18:02: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 SAA06509 for ; Thu, 1 Apr 2004 18:02:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9BCg-0006wg-00 for disman-web-archive@ietf.org; Thu, 01 Apr 2004 18:02:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9BBj-0006rI-00 for disman-web-archive@ietf.org; Thu, 01 Apr 2004 18:01:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9BBH-0006lo-00 for disman-web-archive@ietf.org; Thu, 01 Apr 2004 18:01:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B994r-0006IY-Jp for disman-web-archive@ietf.org; Thu, 01 Apr 2004 15:46:17 -0500 Date: Thu, 01 Apr 2004 11:17:21 -0500 Message-ID: <20040401161721.11029.49466.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.7 required=5.0 tests=AWL,DATE_IN_PAST_03_06, 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 Fri Apr 2 00:33:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10777 for ; Fri, 2 Apr 2004 00:33:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9E7B-0005D7-Jd; Thu, 01 Apr 2004 21:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9BOJ-0002bE-6O for disman@optimus.ietf.org; Thu, 01 Apr 2004 18:14: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 SAA07649 for ; Thu, 1 Apr 2004 18:14:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9BOG-0000JW-00 for disman@ietf.org; Thu, 01 Apr 2004 18:14:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9BNH-0000Ch-00 for disman@ietf.org; Thu, 01 Apr 2004 18:13:28 -0500 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1B9BMT-00007Z-00; Thu, 01 Apr 2004 18:12:37 -0500 Received: from h-68-164-86-83.snvacaid.dynamic.covad.net ([68.164.86.83] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1B9BMT-0007jN-00; Thu, 01 Apr 2004 15:12:37 -0800 Message-ID: <019701c4183f$3c26d280$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Disman] Seoul minutes of disman WG session 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, 1 Apr 2004 15:15:34 -0800 Hi - Minutes for the disman WG session in Seoul The Distributed Management (disman) Working group met for one hour at the IETF meeting at the Lotte Hotel in Seoul on Tuesday, March 2, 2003. Randy Presuhn chaired the session. Shailaja Yadawad and Dan Romascanu kindly provided the notes from which these minutes were assembled. No changes were needed to the posted agenda. The first major item was the review of the status of current work. The Alarm Report Control MIB module was in the RFC editor queue. The Alarm MIB was still in the IESG, and had not yet reached the RFC editor. Sharon Chisholm, one of the document's editors, took the action item to contact the area director, and to inform the WG chair if there were any remaining problems. The Remote Operations MIB update was in working group last call, with only one comment received. The group needs feedback before forwarding it to the IESG. A quick poll of the room revealed that many there had not yet read the update to the Remote Operations MIB, RFC 2925. Consequently an action item for the room was to read the update I-D. The chair will send a request for interoperability reports. The Script MIB appears to be ready to advance to Draft Standard. It is deployed and used, but there was the question of finding editorial resources. Juergen Schoenwaelder, the primary editor, was not at the session. The WG chair took the action item to determine whether there was WG consensus to advance the RFC "as is" since there were no known technical problems, and to request interoperability reports. The situation with the Schedule MIB was identical to that with the Script MIB, so the WG chair took the action item to determine whether it, too, could be advanced "as is". The WG chair called for volunteers to provide editorial assistance. (Subsequently, we heard from the current editor that he'd be able to do this.) Mixed feedback was expressed about the expression MIB. Some find the MIB complicated to implement, and while other members shared how customers are using this MIB. WG members to share implementation reports. Currently only one implementation is known, and there are questions about whether it is worth investing additional effort in this. Only one implementation of the event MIB was discussed in the session. Since Cisco is using it, Elliot Lear would take it as editor if there is another vendor that does it. (Subsequently we learned from Wes Hardaker, who was not able to attend the meeting, that the Event MIB is fairly heavily used by Net-SNMP users, though only for local agent queries.) WG members need to share implementation reports on the Event MIB, RFC 2981. The updates to the Notification Log MIB (RFC 3014) appear to be in fairly good shape for advancement to Draft Standard, but due to workload a new editor is needed to handle these mostly administrative details. The next major item was the review of liaison activity, an item from the ITU on the "structured" probable cause work. Sharon Chisholm agreed to forward the URL of the original liaison to the WG mailing list. Bert Wijnen, our Area Director, provided some helpful clarification on liaisons; the WG chair should email responses directly, copying to Bert and Scott Bradner. The next major item was Juergen Quittek's presentation on an alternative his colleagues implemented to the expression MIB. The discussion focused on why their proposal would be easier to configure or lighter weight than the Expression MIB. In subsequent discussion, Juergen took an action item to determine whether the problem could be solved using objects from RMON groups. The next presentation, by Shailaja Yadawad, provided another look at how the expression MIB problems might be addressed. Entitled "Advanced History Collection", it was inspired by RMON work. The main question was how this MIB could simplify configuration. There was limited discussion, since the I-D had missed the cutoff date. It was agreed that additional discussion would be appropriate on the mailing list after the draft became available. Shailaja took the action item to submit the draft. The group then briefly discussed milestone updates for the charter. The chair will submit proposals to the list, and then, if agreed, to Bert. From exim@www1.ietf.org Fri Apr 2 07:46:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07231 for ; Fri, 2 Apr 2004 07:46: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 1B9L81-0006jL-Tx for disman-archive@odin.ietf.org; Fri, 02 Apr 2004 04:38:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i329cLDP025872 for disman-archive@odin.ietf.org; Fri, 2 Apr 2004 04:38:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9HK9-0004aa-7i for disman-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 00:34: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 AAA10839 for ; Fri, 2 Apr 2004 00:34:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9HK6-0006XI-00 for disman-web-archive@ietf.org; Fri, 02 Apr 2004 00:34:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9HJA-0006Ra-00 for disman-web-archive@ietf.org; Fri, 02 Apr 2004 00:33:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9HIG-0006M4-00 for disman-web-archive@ietf.org; Fri, 02 Apr 2004 00:32:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9E7B-0005D7-Jd; Thu, 01 Apr 2004 21:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9BOJ-0002bE-6O for disman@optimus.ietf.org; Thu, 01 Apr 2004 18:14: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 SAA07649 for ; Thu, 1 Apr 2004 18:14:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9BOG-0000JW-00 for disman@ietf.org; Thu, 01 Apr 2004 18:14:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9BNH-0000Ch-00 for disman@ietf.org; Thu, 01 Apr 2004 18:13:28 -0500 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1B9BMT-00007Z-00; Thu, 01 Apr 2004 18:12:37 -0500 Received: from h-68-164-86-83.snvacaid.dynamic.covad.net ([68.164.86.83] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1B9BMT-0007jN-00; Thu, 01 Apr 2004 15:12:37 -0800 Message-ID: <019701c4183f$3c26d280$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: "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] Seoul minutes of disman WG session 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, 1 Apr 2004 15:15:34 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - Minutes for the disman WG session in Seoul The Distributed Management (disman) Working group met for one hour at the IETF meeting at the Lotte Hotel in Seoul on Tuesday, March 2, 2003. Randy Presuhn chaired the session. Shailaja Yadawad and Dan Romascanu kindly provided the notes from which these minutes were assembled. No changes were needed to the posted agenda. The first major item was the review of the status of current work. The Alarm Report Control MIB module was in the RFC editor queue. The Alarm MIB was still in the IESG, and had not yet reached the RFC editor. Sharon Chisholm, one of the document's editors, took the action item to contact the area director, and to inform the WG chair if there were any remaining problems. The Remote Operations MIB update was in working group last call, with only one comment received. The group needs feedback before forwarding it to the IESG. A quick poll of the room revealed that many there had not yet read the update to the Remote Operations MIB, RFC 2925. Consequently an action item for the room was to read the update I-D. The chair will send a request for interoperability reports. The Script MIB appears to be ready to advance to Draft Standard. It is deployed and used, but there was the question of finding editorial resources. Juergen Schoenwaelder, the primary editor, was not at the session. The WG chair took the action item to determine whether there was WG consensus to advance the RFC "as is" since there were no known technical problems, and to request interoperability reports. The situation with the Schedule MIB was identical to that with the Script MIB, so the WG chair took the action item to determine whether it, too, could be advanced "as is". The WG chair called for volunteers to provide editorial assistance. (Subsequently, we heard from the current editor that he'd be able to do this.) Mixed feedback was expressed about the expression MIB. Some find the MIB complicated to implement, and while other members shared how customers are using this MIB. WG members to share implementation reports. Currently only one implementation is known, and there are questions about whether it is worth investing additional effort in this. Only one implementation of the event MIB was discussed in the session. Since Cisco is using it, Elliot Lear would take it as editor if there is another vendor that does it. (Subsequently we learned from Wes Hardaker, who was not able to attend the meeting, that the Event MIB is fairly heavily used by Net-SNMP users, though only for local agent queries.) WG members need to share implementation reports on the Event MIB, RFC 2981. The updates to the Notification Log MIB (RFC 3014) appear to be in fairly good shape for advancement to Draft Standard, but due to workload a new editor is needed to handle these mostly administrative details. The next major item was the review of liaison activity, an item from the ITU on the "structured" probable cause work. Sharon Chisholm agreed to forward the URL of the original liaison to the WG mailing list. Bert Wijnen, our Area Director, provided some helpful clarification on liaisons; the WG chair should email responses directly, copying to Bert and Scott Bradner. The next major item was Juergen Quittek's presentation on an alternative his colleagues implemented to the expression MIB. The discussion focused on why their proposal would be easier to configure or lighter weight than the Expression MIB. In subsequent discussion, Juergen took an action item to determine whether the problem could be solved using objects from RMON groups. The next presentation, by Shailaja Yadawad, provided another look at how the expression MIB problems might be addressed. Entitled "Advanced History Collection", it was inspired by RMON work. The main question was how this MIB could simplify configuration. There was limited discussion, since the I-D had missed the cutoff date. It was agreed that additional discussion would be appropriate on the mailing list after the draft became available. Shailaja took the action item to submit the draft. The group then briefly discussed milestone updates for the charter. The chair will submit proposals to the list, and then, if agreed, to Bert. From disman-admin@ietf.org Fri Apr 2 07:52:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07435 for ; Fri, 2 Apr 2004 07:52: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 1B9L8j-0006qG-Pz; Fri, 02 Apr 2004 04:39:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9HRu-0004pS-VV for disman@optimus.ietf.org; Fri, 02 Apr 2004 00:42: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 AAA10946 for ; Fri, 2 Apr 2004 00:42:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9HRs-0007J6-00 for disman@ietf.org; Fri, 02 Apr 2004 00:42:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9HQu-0007DJ-00 for disman@ietf.org; Fri, 02 Apr 2004 00:41:36 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9HQ0-00076M-00; Fri, 02 Apr 2004 00:40:40 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i325eZM01259; Thu, 1 Apr 2004 21:40:35 -0800 Message-Id: <5.2.0.9.2.20040401213855.02344df8@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: "Randy Presuhn" , From: "David T. Perkins" Subject: Re: [Disman] Seoul minutes of disman WG session Cc: "Disman \(E-mail\)" In-Reply-To: <019701c4183f$3c26d280$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 01 Apr 2004 21:40:13 -0800 HI, The notification log MIB last I remember had no interoperable implementations. Who has implemented it? At 03:15 PM 4/1/2004 -0800, Randy Presuhn wrote: >Hi - > >Minutes for the disman WG session in Seoul > >The Distributed Management (disman) Working group met for one hour at >the IETF meeting at the Lotte Hotel in Seoul on Tuesday, March 2, 2003. >Randy Presuhn chaired the session. Shailaja Yadawad and Dan Romascanu >kindly provided the notes from which these minutes were assembled. > >No changes were needed to the posted agenda. > >The first major item was the review of the status of current work. >The Alarm Report Control MIB module was in the RFC editor queue. >The Alarm MIB was still in the IESG, and had not yet reached the RFC editor. >Sharon Chisholm, one of the document's editors, took the action item to contact >the area director, and to inform the WG chair if there were any remaining problems. > >The Remote Operations MIB update was in working group last call, with only one >comment received. The group needs feedback before forwarding it to the IESG. >A quick poll of the room revealed that many there had not yet read the >update to the Remote Operations MIB, RFC 2925. Consequently an >action item for the room was to read the update I-D. The chair will send a >request for interoperability reports. > >The Script MIB appears to be ready to advance to Draft Standard. It is deployed >and used, but there was the question of finding editorial resources. Juergen >Schoenwaelder, the primary editor, was not at the session. The WG chair took >the action item to determine whether there was WG consensus to advance the >RFC "as is" since there were no known technical problems, and to request >interoperability reports. > >The situation with the Schedule MIB was identical to that with the Script MIB, so >the WG chair took the action item to determine whether it, too, could be advanced >"as is". The WG chair called for volunteers to provide editorial assistance. (Subsequently, > we heard from the current editor that he'd be able to do this.) > > >Mixed feedback was expressed about the expression MIB. Some find the >MIB complicated to implement, and while other members shared how customers >are using this MIB. WG members to share implementation reports. Currently only >one implementation is known, and there are questions about whether it is worth >investing additional effort in this. > >Only one implementation of the event MIB was discussed in the session. Since Cisco >is using it, Elliot Lear would take it as editor if there is another vendor that does it. >(Subsequently we learned from Wes Hardaker, who was not able to attend the >meeting, that the Event MIB is fairly heavily used by Net-SNMP users, though only >for local agent queries.) WG members need to share implementation reports on >the Event MIB, RFC 2981. > >The updates to the Notification Log MIB (RFC 3014) appear to be in >fairly good shape for advancement to Draft Standard, but due to workload >a new editor is needed to handle these mostly administrative details. > >The next major item was the review of liaison activity, an item from the ITU on >the "structured" probable cause work. Sharon Chisholm agreed to >forward the URL of the original liaison to the WG mailing list. Bert Wijnen, >our Area Director, provided some helpful clarification on liaisons; the WG >chair should email responses directly, copying to Bert and Scott Bradner. > >The next major item was Juergen Quittek's presentation on an alternative his >colleagues implemented to the expression MIB. The discussion focused on >why their proposal would be easier to configure or lighter weight than the >Expression MIB. In subsequent discussion, Juergen took an action >item to determine whether the problem could be solved using objects >from RMON groups. > >The next presentation, by Shailaja Yadawad, provided another look at how the >expression MIB problems might be addressed. Entitled "Advanced History Collection", >it was inspired by RMON work. The main question was how this MIB could >simplify configuration. There was limited discussion, since the I-D had missed >the cutoff date. It was agreed that additional discussion would be appropriate >on the mailing list after the draft became available. Shailaja took the action >item to submit the draft. > >The group then briefly discussed milestone updates for the charter. The chair will >submit proposals to the list, and then, if agreed, to Bert. Regards, /david t. perkins From exim@www1.ietf.org Fri Apr 2 12:45:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20705 for ; Fri, 2 Apr 2004 12:45: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 1B9R4g-0008B1-UR for disman-archive@odin.ietf.org; Fri, 02 Apr 2004 10:59:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32FxInh031432 for disman-archive@odin.ietf.org; Fri, 2 Apr 2004 10:59:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9OBM-0006ts-SK for disman-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 07:54:00 -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 HAA07510 for ; Fri, 2 Apr 2004 07:53:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9OBM-0002lZ-00 for disman-web-archive@ietf.org; Fri, 02 Apr 2004 07:54:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9OAR-0002eB-00 for disman-web-archive@ietf.org; Fri, 02 Apr 2004 07:53:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9O9h-0002Vt-00 for disman-web-archive@ietf.org; Fri, 02 Apr 2004 07:52:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9L8j-0006qG-Pz; Fri, 02 Apr 2004 04:39:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9HRu-0004pS-VV for disman@optimus.ietf.org; Fri, 02 Apr 2004 00:42: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 AAA10946 for ; Fri, 2 Apr 2004 00:42:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9HRs-0007J6-00 for disman@ietf.org; Fri, 02 Apr 2004 00:42:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9HQu-0007DJ-00 for disman@ietf.org; Fri, 02 Apr 2004 00:41:36 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9HQ0-00076M-00; Fri, 02 Apr 2004 00:40:40 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i325eZM01259; Thu, 1 Apr 2004 21:40:35 -0800 Message-Id: <5.2.0.9.2.20040401213855.02344df8@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: "Randy Presuhn" , From: "David T. Perkins" Subject: Re: [Disman] Seoul minutes of disman WG session Cc: "Disman \(E-mail\)" In-Reply-To: <019701c4183f$3c26d280$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 01 Apr 2004 21:40:13 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 HI, The notification log MIB last I remember had no interoperable implementations. Who has implemented it? At 03:15 PM 4/1/2004 -0800, Randy Presuhn wrote: >Hi - > >Minutes for the disman WG session in Seoul > >The Distributed Management (disman) Working group met for one hour at >the IETF meeting at the Lotte Hotel in Seoul on Tuesday, March 2, 2003. >Randy Presuhn chaired the session. Shailaja Yadawad and Dan Romascanu >kindly provided the notes from which these minutes were assembled. > >No changes were needed to the posted agenda. > >The first major item was the review of the status of current work. >The Alarm Report Control MIB module was in the RFC editor queue. >The Alarm MIB was still in the IESG, and had not yet reached the RFC editor. >Sharon Chisholm, one of the document's editors, took the action item to contact >the area director, and to inform the WG chair if there were any remaining problems. > >The Remote Operations MIB update was in working group last call, with only one >comment received. The group needs feedback before forwarding it to the IESG. >A quick poll of the room revealed that many there had not yet read the >update to the Remote Operations MIB, RFC 2925. Consequently an >action item for the room was to read the update I-D. The chair will send a >request for interoperability reports. > >The Script MIB appears to be ready to advance to Draft Standard. It is deployed >and used, but there was the question of finding editorial resources. Juergen >Schoenwaelder, the primary editor, was not at the session. The WG chair took >the action item to determine whether there was WG consensus to advance the >RFC "as is" since there were no known technical problems, and to request >interoperability reports. > >The situation with the Schedule MIB was identical to that with the Script MIB, so >the WG chair took the action item to determine whether it, too, could be advanced >"as is". The WG chair called for volunteers to provide editorial assistance. (Subsequently, > we heard from the current editor that he'd be able to do this.) > > >Mixed feedback was expressed about the expression MIB. Some find the >MIB complicated to implement, and while other members shared how customers >are using this MIB. WG members to share implementation reports. Currently only >one implementation is known, and there are questions about whether it is worth >investing additional effort in this. > >Only one implementation of the event MIB was discussed in the session. Since Cisco >is using it, Elliot Lear would take it as editor if there is another vendor that does it. >(Subsequently we learned from Wes Hardaker, who was not able to attend the >meeting, that the Event MIB is fairly heavily used by Net-SNMP users, though only >for local agent queries.) WG members need to share implementation reports on >the Event MIB, RFC 2981. > >The updates to the Notification Log MIB (RFC 3014) appear to be in >fairly good shape for advancement to Draft Standard, but due to workload >a new editor is needed to handle these mostly administrative details. > >The next major item was the review of liaison activity, an item from the ITU on >the "structured" probable cause work. Sharon Chisholm agreed to >forward the URL of the original liaison to the WG mailing list. Bert Wijnen, >our Area Director, provided some helpful clarification on liaisons; the WG >chair should email responses directly, copying to Bert and Scott Bradner. > >The next major item was Juergen Quittek's presentation on an alternative his >colleagues implemented to the expression MIB. The discussion focused on >why their proposal would be easier to configure or lighter weight than the >Expression MIB. In subsequent discussion, Juergen took an action >item to determine whether the problem could be solved using objects >from RMON groups. > >The next presentation, by Shailaja Yadawad, provided another look at how the >expression MIB problems might be addressed. Entitled "Advanced History Collection", >it was inspired by RMON work. The main question was how this MIB could >simplify configuration. There was limited discussion, since the I-D had missed >the cutoff date. It was agreed that additional discussion would be appropriate >on the mailing list after the draft became available. Shailaja took the action >item to submit the draft. > >The group then briefly discussed milestone updates for the charter. The chair will >submit proposals to the list, and then, if agreed, to Bert. Regards, /david t. perkins From disman-admin@ietf.org Mon Apr 5 16:04:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03500 for ; Mon, 5 Apr 2004 16:04:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaK9-00037J-7Y; Mon, 05 Apr 2004 16:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaJR-000308-1Y for disman@optimus.ietf.org; Mon, 05 Apr 2004 16:03:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03185 for ; Mon, 5 Apr 2004 16:03:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaJP-0004O0-00 for disman@ietf.org; Mon, 05 Apr 2004 16:03:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAa7s-0002NM-00 for disman@ietf.org; Mon, 05 Apr 2004 15:51:21 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1BAZiK-0007cm-00 for disman@ietf.org; Mon, 05 Apr 2004 15:24:56 -0400 Received: from h-68-164-78-136.snvacaid.dynamic.covad.net ([68.164.78.136] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BAZiK-0000iJ-00 for disman@ietf.org; Mon, 05 Apr 2004 12:24:56 -0700 Message-ID: <00b601c41b44$1c123d60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Disman] Event MIB Implementation Survey 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, 5 Apr 2004 12:28:01 -0700 Hi - Here is the Implementation Survey for RFC 2981, the Event MIB. Please send responses to disman@ietf.org , or, if you would like your implementation to remain anonymous for the implementation report, to the WG chair at randy_presuhn@mindspring.com. ================================================= Implementation Survey for RFC 2981, Event MIB Module: DISMAN-EVENT-MIB Implemtation Source: Management Application / Agent: GROUPs: dismanEventResourceGroup (y/n): _ dismanEventTriggerGroup (y/n): _ dismanEventObjectsGroup (y/n): _ dismanEventEventGroup (y/n): _ dismanEventNotificationObjectGroup (y/n): _ dismanEventNotificationGroup (y/n): _ OBJECTs: mteTriggerTargetTag (ro/rw): __ mteEventSetTargetTag (ro/rw): __ mteTriggerValueIDWildcard (ro/rw): __ mteTriggerContextNameWildcard (ro/rw): __ mteObjectsIDWildcard (ro/rw): __ mteEventSetContextNameWildcard (ro/rw): __ Deployment / Operational Experience: Comments: From disman-admin@ietf.org Mon Apr 5 16:05:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03855 for ; Mon, 5 Apr 2004 16:05:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaLA-0003eY-3C; Mon, 05 Apr 2004 16:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaKP-0003Lx-0w for disman@optimus.ietf.org; Mon, 05 Apr 2004 16:04:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03428 for ; Mon, 5 Apr 2004 16:04:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaKN-0004ZM-00 for disman@ietf.org; Mon, 05 Apr 2004 16:04:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAaAk-0002p6-00 for disman@ietf.org; Mon, 05 Apr 2004 15:54:20 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1BAZmd-00009h-00 for disman@ietf.org; Mon, 05 Apr 2004 15:29:23 -0400 Received: from h-68-164-78-136.snvacaid.dynamic.covad.net ([68.164.78.136] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BAZmd-0001ZI-00 for disman@ietf.org; Mon, 05 Apr 2004 12:29:23 -0700 Message-ID: <00ca01c41b44$bb04da40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Disman] Schedule MIB Implementation Survey 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, 5 Apr 2004 12:32:26 -0700 Hi - Here is the Implementation Survey for RFC 3231, the Schedule MIB. Please send responses to disman@ietf.org , or, if you would like your implementation to remain anonymous for the implementation report, to the WG chair at randy_presuhn@mindspring.com. ================================= Implementation Survey for RFC 3231, Definitions of Managed Objects for Scheduling Management Operations Module: DISMAN-SCHEDULE-MIB Implementation Source: Management Application / Agent: GROUPs schedGroup2 (y/n): _ schedNotificationsGroup (y/n): _ schedCalendarGroup (y,n): _ Deployment / Operational Experience: Comments: From exim@www1.ietf.org Mon Apr 5 16:43:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05179 for ; Mon, 5 Apr 2004 16:43:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAavo-0004Q5-NC for disman-archive@odin.ietf.org; Mon, 05 Apr 2004 16:42:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35Kguqw016987 for disman-archive@odin.ietf.org; Mon, 5 Apr 2004 16:42:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAavo-0004Pu-Ce for disman-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 16:42:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05137 for ; Mon, 5 Apr 2004 16:42:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAavm-0000Lh-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:42:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAaOH-0005NN-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:08:18 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAaLD-0004kD-01 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:05:07 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAaLC-0005l6-1m for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:05:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaLA-0003eY-3C; Mon, 05 Apr 2004 16:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaKP-0003Lx-0w for disman@optimus.ietf.org; Mon, 05 Apr 2004 16:04:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03428 for ; Mon, 5 Apr 2004 16:04:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaKN-0004ZM-00 for disman@ietf.org; Mon, 05 Apr 2004 16:04:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAaAk-0002p6-00 for disman@ietf.org; Mon, 05 Apr 2004 15:54:20 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1BAZmd-00009h-00 for disman@ietf.org; Mon, 05 Apr 2004 15:29:23 -0400 Received: from h-68-164-78-136.snvacaid.dynamic.covad.net ([68.164.78.136] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BAZmd-0001ZI-00 for disman@ietf.org; Mon, 05 Apr 2004 12:29:23 -0700 Message-ID: <00ca01c41b44$bb04da40$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] Schedule MIB Implementation Survey 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, 5 Apr 2004 12:32:26 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - Here is the Implementation Survey for RFC 3231, the Schedule MIB. Please send responses to disman@ietf.org , or, if you would like your implementation to remain anonymous for the implementation report, to the WG chair at randy_presuhn@mindspring.com. ================================= Implementation Survey for RFC 3231, Definitions of Managed Objects for Scheduling Management Operations Module: DISMAN-SCHEDULE-MIB Implementation Source: Management Application / Agent: GROUPs schedGroup2 (y/n): _ schedNotificationsGroup (y/n): _ schedCalendarGroup (y,n): _ Deployment / Operational Experience: Comments: From exim@www1.ietf.org Mon Apr 5 16:43:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05242 for ; Mon, 5 Apr 2004 16:43:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAawN-0004Rh-Ei for disman-archive@odin.ietf.org; Mon, 05 Apr 2004 16:43:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35KhVfk017085 for disman-archive@odin.ietf.org; Mon, 5 Apr 2004 16:43:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAawN-0004RU-Ba for disman-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 16:43:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05205 for ; Mon, 5 Apr 2004 16:43:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAawL-0000Q8-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:43:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAaOX-0005QJ-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:08:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAaLH-0004kD-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:05:11 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAaKg-0005h4-Pa for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:04:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaK8-00036m-Uk; Mon, 05 Apr 2004 16:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaJN-0002zx-Fu for disman@optimus.ietf.org; Mon, 05 Apr 2004 16:03:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03182 for ; Mon, 5 Apr 2004 16:03:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaJL-0004ND-00 for disman@ietf.org; Mon, 05 Apr 2004 16:03:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAa7Z-0002Jb-00 for disman@ietf.org; Mon, 05 Apr 2004 15:51:02 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1BAZh1-0007Ww-00 for disman@ietf.org; Mon, 05 Apr 2004 15:23:36 -0400 Received: from h-68-164-78-136.snvacaid.dynamic.covad.net ([68.164.78.136] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BAZh1-0000Mi-00 for disman@ietf.org; Mon, 05 Apr 2004 12:23:35 -0700 Message-ID: <00b001c41b43$ec031400$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] Script MIB Implementation Survey 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, 5 Apr 2004 12:26:40 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - Here is the Implementation Survey for RFC 3165, the Script MIB. Please send responses to disman@ietf.org , or, if you would like your implementation to remain anonymous for the implementation report, to the WG chair at randy_presuhn@mindspring.com. ================================================= Implementation Survey for RFC 3165, Definitions of Managed Objects for the Delegation of Management Scripts Module: DISMAN-SCRIPT-MIB Implementation Source: ____________ Management Application / Agent: GROUPs: smLanguageGroup (y/n): _ smScriptGroup2 (y/n): _ smLaunchGroup2 (y/n): _ smRunGroup2 (y/n): _ smNotificationsGroup2 (y,n): _ smCodeGroup (y,n): _ OBJECTs: smScriptSource (ro/rw): __ smCodeText (ro/rw): __ smLaunchArgument maximum size: __ smRunArgument maximum size: ___ smRunResult maximum size: ___ smRunState suspension permitted? (y,n): _ Deployement / P[erational Experience: Comments: From exim@www1.ietf.org Mon Apr 5 16:44:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05265 for ; Mon, 5 Apr 2004 16:44:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAawS-0004Rv-Q1 for disman-archive@odin.ietf.org; Mon, 05 Apr 2004 16:43:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35Kha83017101 for disman-archive@odin.ietf.org; Mon, 5 Apr 2004 16:43:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAawS-0004Rk-Mu for disman-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 16:43:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05209 for ; Mon, 5 Apr 2004 16:43:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAawQ-0000QY-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:43:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAaOY-0005QY-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:08:35 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAaLH-0004kD-01 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:05:11 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAaKg-0005h3-PU for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:04:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaK9-000381-PU; Mon, 05 Apr 2004 16:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaJU-00032W-OM for disman@optimus.ietf.org; Mon, 05 Apr 2004 16:03:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03201 for ; Mon, 5 Apr 2004 16:03:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaJS-0004Ol-00 for disman@ietf.org; Mon, 05 Apr 2004 16:03:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAa8A-0002RH-00 for disman@ietf.org; Mon, 05 Apr 2004 15:51:39 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1BAZjL-0007hL-00 for disman@ietf.org; Mon, 05 Apr 2004 15:25:59 -0400 Received: from h-68-164-78-136.snvacaid.dynamic.covad.net ([68.164.78.136] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BAZjK-0000wv-00 for disman@ietf.org; Mon, 05 Apr 2004 12:25:58 -0700 Message-ID: <00c101c41b44$40bd7260$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] Log MIB Implementation Survey 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, 5 Apr 2004 12:29:02 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - Here is the Implementation Survey for RFC 3014, the Log MIB. Please send responses to disman@ietf.org , or, if you would like your implementation to remain anonymous for the implementation report, to the WG chair at randy_presuhn@mindspring.com. ================================================= Implementation Survey for RFC 3014, Notification Log MIB Module: NOTIFICATION-LOG-MIB Implementation Source: Management Application / Agent: GROUPs: notificationLogConfigGroup (y/n): _ notificationLogStatsGroup (y/n): _ notificationLogLogGroup (y/n): notificationLogDateGroup (y/n): _ OBJECTs: nlmConfigGlobalEntryLimit (rw/ro): _ lower bound: _______ upper bound: _______ nlmConfigLogEntryLimit (rw/ro): _ lower bound: ________ upper bound: ________ nlmConfigLogEntryStatus: (rw/ro): _ Deployment / Operational Experience: Comments: From exim@www1.ietf.org Mon Apr 5 16:44:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05303 for ; Mon, 5 Apr 2004 16:44:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAawZ-0004SE-Hl for disman-archive@odin.ietf.org; Mon, 05 Apr 2004 16:43:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35Khhfa017118 for disman-archive@odin.ietf.org; Mon, 5 Apr 2004 16:43:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAawZ-0004S0-ES for disman-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 16:43:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05215 for ; Mon, 5 Apr 2004 16:43:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAawX-0000RI-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:43:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAaOa-0005Qm-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:08:37 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAaLH-0004kD-02 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:05:11 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAaKg-0005h2-PO for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:04:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaK9-00037J-7Y; Mon, 05 Apr 2004 16:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaJR-000308-1Y for disman@optimus.ietf.org; Mon, 05 Apr 2004 16:03:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03185 for ; Mon, 5 Apr 2004 16:03:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaJP-0004O0-00 for disman@ietf.org; Mon, 05 Apr 2004 16:03:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAa7s-0002NM-00 for disman@ietf.org; Mon, 05 Apr 2004 15:51:21 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1BAZiK-0007cm-00 for disman@ietf.org; Mon, 05 Apr 2004 15:24:56 -0400 Received: from h-68-164-78-136.snvacaid.dynamic.covad.net ([68.164.78.136] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BAZiK-0000iJ-00 for disman@ietf.org; Mon, 05 Apr 2004 12:24:56 -0700 Message-ID: <00b601c41b44$1c123d60$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] Event MIB Implementation Survey 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, 5 Apr 2004 12:28:01 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - Here is the Implementation Survey for RFC 2981, the Event MIB. Please send responses to disman@ietf.org , or, if you would like your implementation to remain anonymous for the implementation report, to the WG chair at randy_presuhn@mindspring.com. ================================================= Implementation Survey for RFC 2981, Event MIB Module: DISMAN-EVENT-MIB Implemtation Source: Management Application / Agent: GROUPs: dismanEventResourceGroup (y/n): _ dismanEventTriggerGroup (y/n): _ dismanEventObjectsGroup (y/n): _ dismanEventEventGroup (y/n): _ dismanEventNotificationObjectGroup (y/n): _ dismanEventNotificationGroup (y/n): _ OBJECTs: mteTriggerTargetTag (ro/rw): __ mteEventSetTargetTag (ro/rw): __ mteTriggerValueIDWildcard (ro/rw): __ mteTriggerContextNameWildcard (ro/rw): __ mteObjectsIDWildcard (ro/rw): __ mteEventSetContextNameWildcard (ro/rw): __ Deployment / Operational Experience: Comments: From exim@www1.ietf.org Mon Apr 5 16:44:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05382 for ; Mon, 5 Apr 2004 16:44:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAax4-0004eU-Ha for disman-archive@odin.ietf.org; Mon, 05 Apr 2004 16:44:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35KiEPZ017880 for disman-archive@odin.ietf.org; Mon, 5 Apr 2004 16:44:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAax4-0004eJ-EX for disman-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 16:44:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05321 for ; Mon, 5 Apr 2004 16:44:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAax2-0000Wk-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:44:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAaP0-0005UG-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:09:04 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAaLK-0004ln-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:05:14 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAaKM-0005gz-M5 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:04:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaK8-00036R-Mi; Mon, 05 Apr 2004 16:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaJH-0002yg-6T for disman@optimus.ietf.org; Mon, 05 Apr 2004 16:03:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03163 for ; Mon, 5 Apr 2004 16:03:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaJF-0004M8-00 for disman@ietf.org; Mon, 05 Apr 2004 16:03:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAa7C-0002Ex-00 for disman@ietf.org; Mon, 05 Apr 2004 15:50:39 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1BAZfj-0007Qt-00 for disman@ietf.org; Mon, 05 Apr 2004 15:22:15 -0400 Received: from h-68-164-78-136.snvacaid.dynamic.covad.net ([68.164.78.136] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BAZff-00004M-00 for disman@ietf.org; Mon, 05 Apr 2004 12:22:11 -0700 Message-ID: <00aa01c41b43$b9900a00$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] Remops Implementation Survey 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, 5 Apr 2004 12:25:15 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - Here is the Implementation Survey for RFC 2925, the Remote Operations MIBs. Please send responses to disman@ietf.org , or, if you would like your implementation to remain anonymous for the implementation report, to the WG chair at randy_presuhn@mindspring.com. ================================================= Implementation Survey for RFC 2925, Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations Module: DISMAN-PING-MIB Implementation Source: Management Application / Agent: GROUPs: pingGroup (y/n): _ pingNotificationsGroup (y/n): _ pingTimeStampGroup (y/n): _ OBJECTs: pingMaxConcurrentRequests (rw/ro): __ pingCtlStorageType (rw/ro): __ pingCtlType (rw/ro): __ pingCtlByPassRouteTable (rw/ro): __ pingCtlSourceAddressType (rw/ro): __ unknown (y/n): _ ipv4 (y/n): _ ipv6 (y/n): _ pingCtlSourceAddress (rw/ro): __ pingCtlIfIndex (rw/ro): __ pingCtlDSField (rw/ro): __ pingResultsIpTargetAddressType: unknown (y/n): _ ipv4 (y/n): _ ipv6: _ pingResultsIpTargetAddress: 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ Module: DISMAN-TRACEROUTE-MIB Implementation Source: Management Application / Agent: GROUPs: traceRouteGroup (y/n): _ traceRouteTimeStampGroup (y/n): _ traceRouteNotificationsGroup (y/n): _ traceRouteHopsTableGroup (y/n): OBJECTs: traceRouteMaxConcurrentRequests (rw/ro): __ traceRouteCtlByPassRouteTable (rw/ro): __ traceRouteCtlSourceAddressType rw/ro): __ traceRouteCtlSourceAddress (rw/ro): __ traceRouteCtlIfIndex (rw/ro): __ traceRouteCtlMiscOptions (rw/ro): __ traceRouteCtlStorageType (rw/ro): __ traceRouteCtlDSField (rw/ro): __ traceRouteCtlType (rw/ro): __ traceRouteResultsIpTgtAddrType unknown (y/n): _ ipv4 (y/n): _ ipv6 (y/n): _ traceRouteResultsIpTgtAddr 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ traceRouteProbeHistoryHAddrType unknown (y/n): _ ipv4 (y/n): _ ipv6 (y/n): _ traceRouteProbeHistoryHAddr 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ traceRouteHopsIpTgtAddressType unknown (y/n): _ ipv4 (y/n): _ ipv6 (y/n): _ traceRouteHopsIpTgtAddress 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ Module: DISMAN-NSLOOKUP-MIB Implementation Source: Management Application / Agent: GROUPs lookupGroup (y/n): _ OBJECTs: lookupMaxConcurrentRequests (rw/ro): __ lookupPurgeTime (rw/ro): __ Deployment / Operational Experience: Comments: From exim@www1.ietf.org Mon Apr 5 16:44:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05429 for ; Mon, 5 Apr 2004 16:44:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaxJ-0004fB-Uh for disman-archive@odin.ietf.org; Mon, 05 Apr 2004 16:44:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35KiTmX017921 for disman-archive@odin.ietf.org; Mon, 5 Apr 2004 16:44:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaxJ-0004ey-RO for disman-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 16:44:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05345 for ; Mon, 5 Apr 2004 16:44:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaxH-0000ZE-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:44:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAaP9-0005VX-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:09:12 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAaLL-0004lj-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:05:15 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAaKE-0005hX-Aw for disman-web-archive@ietf.org; Mon, 05 Apr 2004 16:04:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaKD-0003FZ-As; Mon, 05 Apr 2004 16:04:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaJx-00035D-3y for disman@optimus.ietf.org; Mon, 05 Apr 2004 16:03:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03299 for ; Mon, 5 Apr 2004 16:03:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaJv-0004TQ-00 for disman@ietf.org; Mon, 05 Apr 2004 16:03:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAa9R-0002bY-00 for disman@ietf.org; Mon, 05 Apr 2004 15:52:58 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1BAZkW-0007nS-00 for disman@ietf.org; Mon, 05 Apr 2004 15:27:12 -0400 Received: from h-68-164-78-136.snvacaid.dynamic.covad.net ([68.164.78.136] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BAZkW-0001Ac-00 for disman@ietf.org; Mon, 05 Apr 2004 12:27:12 -0700 Message-ID: <00c201c41b44$6d116880$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] Expression MIB Implementation Survey 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, 5 Apr 2004 12:30:17 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - Here is the Implementation Survey for RFC 2982, the Expression MIB. Please send responses to disman@ietf.org , or, if you would like your implementation to remain anonymous for the implementation report, to the WG chair at randy_presuhn@mindspring.com. ================================================= Implementat Survey for RFC 2982, Distributed Management Expression MIB Implementation Source: Management Application / Agent: Module: DISMAN-EXPRESSION-MIB GROUPs: dismanExpressionResourceGroup (y/n): _ dismanExpressionDefinitionGroup (y/n): _ dismanExpressionValueGroup (y,n): _ OBJECTs: expResourceDeltaMinimum full range supported (y/n): _ expObjectSampleType deltas supported (y/n): _ expObjectIDWildcard wildcard supported (y/n): _ expObjectDiscontinuityIDWildcard wildcard supported (y/n): _ expObjectConditionalWildcard deltas/wildcards supported (y/n): _ Deployment / Operational Experience: Comments: From disman-admin@ietf.org Mon Apr 5 16:50:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03499 for ; Mon, 5 Apr 2004 16:04:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaK8-00036m-Uk; Mon, 05 Apr 2004 16:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaJN-0002zx-Fu for disman@optimus.ietf.org; Mon, 05 Apr 2004 16:03:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03182 for ; Mon, 5 Apr 2004 16:03:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaJL-0004ND-00 for disman@ietf.org; Mon, 05 Apr 2004 16:03:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAa7Z-0002Jb-00 for disman@ietf.org; Mon, 05 Apr 2004 15:51:02 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1BAZh1-0007Ww-00 for disman@ietf.org; Mon, 05 Apr 2004 15:23:36 -0400 Received: from h-68-164-78-136.snvacaid.dynamic.covad.net ([68.164.78.136] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BAZh1-0000Mi-00 for disman@ietf.org; Mon, 05 Apr 2004 12:23:35 -0700 Message-ID: <00b001c41b43$ec031400$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Disman] Script MIB Implementation Survey 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, 5 Apr 2004 12:26:40 -0700 Hi - Here is the Implementation Survey for RFC 3165, the Script MIB. Please send responses to disman@ietf.org , or, if you would like your implementation to remain anonymous for the implementation report, to the WG chair at randy_presuhn@mindspring.com. ================================================= Implementation Survey for RFC 3165, Definitions of Managed Objects for the Delegation of Management Scripts Module: DISMAN-SCRIPT-MIB Implementation Source: ____________ Management Application / Agent: GROUPs: smLanguageGroup (y/n): _ smScriptGroup2 (y/n): _ smLaunchGroup2 (y/n): _ smRunGroup2 (y/n): _ smNotificationsGroup2 (y,n): _ smCodeGroup (y,n): _ OBJECTs: smScriptSource (ro/rw): __ smCodeText (ro/rw): __ smLaunchArgument maximum size: __ smRunArgument maximum size: ___ smRunResult maximum size: ___ smRunState suspension permitted? (y,n): _ Deployement / P[erational Experience: Comments: From disman-admin@ietf.org Mon Apr 5 16:50:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03513 for ; Mon, 5 Apr 2004 16:04:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaKD-0003FZ-As; Mon, 05 Apr 2004 16:04:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaJx-00035D-3y for disman@optimus.ietf.org; Mon, 05 Apr 2004 16:03:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03299 for ; Mon, 5 Apr 2004 16:03:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaJv-0004TQ-00 for disman@ietf.org; Mon, 05 Apr 2004 16:03:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAa9R-0002bY-00 for disman@ietf.org; Mon, 05 Apr 2004 15:52:58 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1BAZkW-0007nS-00 for disman@ietf.org; Mon, 05 Apr 2004 15:27:12 -0400 Received: from h-68-164-78-136.snvacaid.dynamic.covad.net ([68.164.78.136] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BAZkW-0001Ac-00 for disman@ietf.org; Mon, 05 Apr 2004 12:27:12 -0700 Message-ID: <00c201c41b44$6d116880$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Disman] Expression MIB Implementation Survey 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, 5 Apr 2004 12:30:17 -0700 Hi - Here is the Implementation Survey for RFC 2982, the Expression MIB. Please send responses to disman@ietf.org , or, if you would like your implementation to remain anonymous for the implementation report, to the WG chair at randy_presuhn@mindspring.com. ================================================= Implementat Survey for RFC 2982, Distributed Management Expression MIB Implementation Source: Management Application / Agent: Module: DISMAN-EXPRESSION-MIB GROUPs: dismanExpressionResourceGroup (y/n): _ dismanExpressionDefinitionGroup (y/n): _ dismanExpressionValueGroup (y,n): _ OBJECTs: expResourceDeltaMinimum full range supported (y/n): _ expObjectSampleType deltas supported (y/n): _ expObjectIDWildcard wildcard supported (y/n): _ expObjectDiscontinuityIDWildcard wildcard supported (y/n): _ expObjectConditionalWildcard deltas/wildcards supported (y/n): _ Deployment / Operational Experience: Comments: From disman-admin@ietf.org Mon Apr 5 16:50:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03501 for ; Mon, 5 Apr 2004 16:04:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaK9-000381-PU; Mon, 05 Apr 2004 16:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaJU-00032W-OM for disman@optimus.ietf.org; Mon, 05 Apr 2004 16:03:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03201 for ; Mon, 5 Apr 2004 16:03:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaJS-0004Ol-00 for disman@ietf.org; Mon, 05 Apr 2004 16:03:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAa8A-0002RH-00 for disman@ietf.org; Mon, 05 Apr 2004 15:51:39 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1BAZjL-0007hL-00 for disman@ietf.org; Mon, 05 Apr 2004 15:25:59 -0400 Received: from h-68-164-78-136.snvacaid.dynamic.covad.net ([68.164.78.136] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BAZjK-0000wv-00 for disman@ietf.org; Mon, 05 Apr 2004 12:25:58 -0700 Message-ID: <00c101c41b44$40bd7260$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Disman] Log MIB Implementation Survey 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, 5 Apr 2004 12:29:02 -0700 Hi - Here is the Implementation Survey for RFC 3014, the Log MIB. Please send responses to disman@ietf.org , or, if you would like your implementation to remain anonymous for the implementation report, to the WG chair at randy_presuhn@mindspring.com. ================================================= Implementation Survey for RFC 3014, Notification Log MIB Module: NOTIFICATION-LOG-MIB Implementation Source: Management Application / Agent: GROUPs: notificationLogConfigGroup (y/n): _ notificationLogStatsGroup (y/n): _ notificationLogLogGroup (y/n): notificationLogDateGroup (y/n): _ OBJECTs: nlmConfigGlobalEntryLimit (rw/ro): _ lower bound: _______ upper bound: _______ nlmConfigLogEntryLimit (rw/ro): _ lower bound: ________ upper bound: ________ nlmConfigLogEntryStatus: (rw/ro): _ Deployment / Operational Experience: Comments: From disman-admin@ietf.org Mon Apr 5 16:50:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03498 for ; Mon, 5 Apr 2004 16:04:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaK8-00036R-Mi; Mon, 05 Apr 2004 16:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaJH-0002yg-6T for disman@optimus.ietf.org; Mon, 05 Apr 2004 16:03:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03163 for ; Mon, 5 Apr 2004 16:03:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaJF-0004M8-00 for disman@ietf.org; Mon, 05 Apr 2004 16:03:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAa7C-0002Ex-00 for disman@ietf.org; Mon, 05 Apr 2004 15:50:39 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1BAZfj-0007Qt-00 for disman@ietf.org; Mon, 05 Apr 2004 15:22:15 -0400 Received: from h-68-164-78-136.snvacaid.dynamic.covad.net ([68.164.78.136] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BAZff-00004M-00 for disman@ietf.org; Mon, 05 Apr 2004 12:22:11 -0700 Message-ID: <00aa01c41b43$b9900a00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Disman] Remops Implementation Survey 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, 5 Apr 2004 12:25:15 -0700 Hi - Here is the Implementation Survey for RFC 2925, the Remote Operations MIBs. Please send responses to disman@ietf.org , or, if you would like your implementation to remain anonymous for the implementation report, to the WG chair at randy_presuhn@mindspring.com. ================================================= Implementation Survey for RFC 2925, Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations Module: DISMAN-PING-MIB Implementation Source: Management Application / Agent: GROUPs: pingGroup (y/n): _ pingNotificationsGroup (y/n): _ pingTimeStampGroup (y/n): _ OBJECTs: pingMaxConcurrentRequests (rw/ro): __ pingCtlStorageType (rw/ro): __ pingCtlType (rw/ro): __ pingCtlByPassRouteTable (rw/ro): __ pingCtlSourceAddressType (rw/ro): __ unknown (y/n): _ ipv4 (y/n): _ ipv6 (y/n): _ pingCtlSourceAddress (rw/ro): __ pingCtlIfIndex (rw/ro): __ pingCtlDSField (rw/ro): __ pingResultsIpTargetAddressType: unknown (y/n): _ ipv4 (y/n): _ ipv6: _ pingResultsIpTargetAddress: 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ Module: DISMAN-TRACEROUTE-MIB Implementation Source: Management Application / Agent: GROUPs: traceRouteGroup (y/n): _ traceRouteTimeStampGroup (y/n): _ traceRouteNotificationsGroup (y/n): _ traceRouteHopsTableGroup (y/n): OBJECTs: traceRouteMaxConcurrentRequests (rw/ro): __ traceRouteCtlByPassRouteTable (rw/ro): __ traceRouteCtlSourceAddressType rw/ro): __ traceRouteCtlSourceAddress (rw/ro): __ traceRouteCtlIfIndex (rw/ro): __ traceRouteCtlMiscOptions (rw/ro): __ traceRouteCtlStorageType (rw/ro): __ traceRouteCtlDSField (rw/ro): __ traceRouteCtlType (rw/ro): __ traceRouteResultsIpTgtAddrType unknown (y/n): _ ipv4 (y/n): _ ipv6 (y/n): _ traceRouteResultsIpTgtAddr 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ traceRouteProbeHistoryHAddrType unknown (y/n): _ ipv4 (y/n): _ ipv6 (y/n): _ traceRouteProbeHistoryHAddr 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ traceRouteHopsIpTgtAddressType unknown (y/n): _ ipv4 (y/n): _ ipv6 (y/n): _ traceRouteHopsIpTgtAddress 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ Module: DISMAN-NSLOOKUP-MIB Implementation Source: Management Application / Agent: GROUPs lookupGroup (y/n): _ OBJECTs: lookupMaxConcurrentRequests (rw/ro): __ lookupPurgeTime (rw/ro): __ Deployment / Operational Experience: Comments: From disman-admin@ietf.org Mon Apr 5 17:07:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09976 for ; Mon, 5 Apr 2004 17:07:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAbJB-00057X-64; Mon, 05 Apr 2004 17:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAbIS-0004ZD-DE for disman@optimus.ietf.org; Mon, 05 Apr 2004 17:06:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09880 for ; Mon, 5 Apr 2004 17:06:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAbIQ-0004ZN-00 for disman@ietf.org; Mon, 05 Apr 2004 17:06:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAbCU-0003R5-00 for disman@ietf.org; Mon, 05 Apr 2004 17:00:11 -0400 Received: from conure.mail.pas.earthlink.net ([207.217.120.54]) by ietf-mx with esmtp (Exim 4.12) id 1BAay8-0000jN-00 for disman@ietf.org; Mon, 05 Apr 2004 16:45:20 -0400 Received: from h-68-164-78-136.snvacaid.dynamic.covad.net ([68.164.78.136] helo=oemcomputer) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BAay7-0002lk-00 for disman@ietf.org; Mon, 05 Apr 2004 13:45:19 -0700 Message-ID: <001a01c41b4f$57124d00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <29620639.1078272709925.JavaMail.root@wamui03.slb.atl.earthlink.net> Subject: Re: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,REMOVE_IN_QUOTES autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 13:47:35 -0700 Hi - I still haven't heard any comments on the proposals below. *Please* let me know what you think, so we can wrap this up! Randy > From: "Randy Presuhn" > To: > Cc: "Ipcdn List (E-mail)" > Sent: Tuesday, March 02, 2004 5:11 PM > Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt > > Hi - > > > From: Eduardo Cardona > > Sent: Mar 3, 2004 2:04 AM > > To: Randy Presuhn , disman@ietf.org > > Cc: "Ipcdn List (E-mail)" > > Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt > ... > > Thanks for the comments! > > ... > > (*) traceRouteCtlMiscOptions > > It appears to me an uncanny object and rather implementations may opt to > > extend the capabilities in the private branch, could leave with that to > > avoid deprecation, of if there are field implementations. > > any suggested changes? > > ... > > Should the proposal below being include in the remops MIB or should we > > update IPCDN cable gateway Tools MIB module to be just the compliance > > statement outlined below? > > Both seem reasonable. If we can include a "basic" compliance statement > to suit your needs without jeopardizing progression, that seems like > an option that I would prefer as a technical contributor, though I > admit that it is not a strong preference and would like to hear other > opinions. > > > RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null named > > log" default entry for devices not supporting the named log > > Named log is analog to disman remops draft for "OwnerIndex" and > > "TestName" where default entries are created > > (null owner, null TestName) for a manager requested operation of PING/ > > TRACEROUTE, NSLOOKUP, mostly for small foot-print devices with no > > network monitoring role at the connectivity level as pretended with this > > updated RFC. > > I have no problem with this in principle, and think it would be > really nice if we can verify that the MIB definitions do not preclude > operating this way. > > > In summary A new Compliance Statement for small devices with no > > monitoring capabilities to : > ... > > I'd phrase it a bit differently. Rather than "remove" information, > I think the proposal is to ensure that it can function meaningfully using > a small subset of the objects. > > I'd like to hear from Juergen (and others) regarding the details of the proposed > compliance material, especially with regard to whether there are > any details in the current object definitions that would prevent this usage. > > Randy > From exim@www1.ietf.org Mon Apr 5 18:10:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15332 for ; Mon, 5 Apr 2004 18:10:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAcHe-00011u-IT for disman-archive@odin.ietf.org; Mon, 05 Apr 2004 18:09:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35M9Ybg003956 for disman-archive@odin.ietf.org; Mon, 5 Apr 2004 18:09:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAcHe-00011Q-BQ for disman-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 18:09:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15168 for ; Mon, 5 Apr 2004 18:09:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAcHb-00041c-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 18:09:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAc1T-0001Qq-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 17:52:52 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAbYA-0005wN-04 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 17:22:34 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAbMq-0002mp-BQ for disman-web-archive@ietf.org; Mon, 05 Apr 2004 17:10:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAbJB-00057X-64; Mon, 05 Apr 2004 17:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAbIS-0004ZD-DE for disman@optimus.ietf.org; Mon, 05 Apr 2004 17:06:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09880 for ; Mon, 5 Apr 2004 17:06:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAbIQ-0004ZN-00 for disman@ietf.org; Mon, 05 Apr 2004 17:06:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAbCU-0003R5-00 for disman@ietf.org; Mon, 05 Apr 2004 17:00:11 -0400 Received: from conure.mail.pas.earthlink.net ([207.217.120.54]) by ietf-mx with esmtp (Exim 4.12) id 1BAay8-0000jN-00 for disman@ietf.org; Mon, 05 Apr 2004 16:45:20 -0400 Received: from h-68-164-78-136.snvacaid.dynamic.covad.net ([68.164.78.136] helo=oemcomputer) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BAay7-0002lk-00 for disman@ietf.org; Mon, 05 Apr 2004 13:45:19 -0700 Message-ID: <001a01c41b4f$57124d00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <29620639.1078272709925.JavaMail.root@wamui03.slb.atl.earthlink.net> Subject: Re: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 13:47:35 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,REMOVE_IN_QUOTES autolearn=no version=2.60 Hi - I still haven't heard any comments on the proposals below. *Please* let me know what you think, so we can wrap this up! Randy > From: "Randy Presuhn" > To: > Cc: "Ipcdn List (E-mail)" > Sent: Tuesday, March 02, 2004 5:11 PM > Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt > > Hi - > > > From: Eduardo Cardona > > Sent: Mar 3, 2004 2:04 AM > > To: Randy Presuhn , disman@ietf.org > > Cc: "Ipcdn List (E-mail)" > > Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt > ... > > Thanks for the comments! > > ... > > (*) traceRouteCtlMiscOptions > > It appears to me an uncanny object and rather implementations may opt to > > extend the capabilities in the private branch, could leave with that to > > avoid deprecation, of if there are field implementations. > > any suggested changes? > > ... > > Should the proposal below being include in the remops MIB or should we > > update IPCDN cable gateway Tools MIB module to be just the compliance > > statement outlined below? > > Both seem reasonable. If we can include a "basic" compliance statement > to suit your needs without jeopardizing progression, that seems like > an option that I would prefer as a technical contributor, though I > admit that it is not a strong preference and would like to hear other > opinions. > > > RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null named > > log" default entry for devices not supporting the named log > > Named log is analog to disman remops draft for "OwnerIndex" and > > "TestName" where default entries are created > > (null owner, null TestName) for a manager requested operation of PING/ > > TRACEROUTE, NSLOOKUP, mostly for small foot-print devices with no > > network monitoring role at the connectivity level as pretended with this > > updated RFC. > > I have no problem with this in principle, and think it would be > really nice if we can verify that the MIB definitions do not preclude > operating this way. > > > In summary A new Compliance Statement for small devices with no > > monitoring capabilities to : > ... > > I'd phrase it a bit differently. Rather than "remove" information, > I think the proposal is to ensure that it can function meaningfully using > a small subset of the objects. > > I'd like to hear from Juergen (and others) regarding the details of the proposed > compliance material, especially with regard to whether there are > any details in the current object definitions that would prevent this usage. > > Randy > From disman-admin@ietf.org Mon Apr 5 22:45:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08389 for ; Mon, 5 Apr 2004 22:45:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAgaD-0000BT-Nx; Mon, 05 Apr 2004 22:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAga3-0000Af-69 for disman@optimus.ietf.org; Mon, 05 Apr 2004 22:44:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08364 for ; Mon, 5 Apr 2004 22:44:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAgZz-0004KJ-00 for disman@ietf.org; Mon, 05 Apr 2004 22:44:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAg9d-0001IS-00 for disman@ietf.org; Mon, 05 Apr 2004 22:17:34 -0400 Received: from swan.mail.pas.earthlink.net ([207.217.120.123]) by ietf-mx with esmtp (Exim 4.12) id 1BAfmD-0005yg-00 for disman@ietf.org; Mon, 05 Apr 2004 21:53:21 -0400 Received: from h-68-164-78-136.snvacaid.dynamic.covad.net ([68.164.78.136] helo=oemcomputer) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BAfmD-0000cq-00 for disman@ietf.org; Mon, 05 Apr 2004 18:53:21 -0700 Message-ID: <002401c41b7a$6013ffe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <2147483647.1075035045@[10.1.1.26]> Subject: Re: [Disman] traceroute-mib-2 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 18:56:27 -0700 Hi - (as technical contributor - sorry for tardiness in commenting, particularly since the WG chair issued last call *long* ago!) > From: "Juergen Quittek" > To: > Sent: Sunday, January 25, 2004 4:50 AM > Subject: [Disman] traceroute-mib-2 > > 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? ... I *think* the motivation for including zero was to allow this MIB to be used to generate relatively obnoxious test PDUs. (I guess a local LAN device might respond to one of these; RFC 791 sounds like it says that they're supposed to be discarded upon receipt, but I'll leave that to the IP experts. If they are supposed to be discarded, then any device that responds is exhibiting an interesting failure mode. (Would these show up in ifInDiscards?) If they are not supposed to be discarded, then we'd be doubly wrong to exclude the value.) I'm not sure that there is any great value in prohibiting zero, and I'd rather not make changes unless there is clear value in doing so. Randy From exim@www1.ietf.org Mon Apr 5 23:38:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12598 for ; Mon, 5 Apr 2004 23:38:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAhPP-0002yY-4b for disman-archive@odin.ietf.org; Mon, 05 Apr 2004 23:37:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i363btDC011439 for disman-archive@odin.ietf.org; Mon, 5 Apr 2004 23:37:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAhPO-0002yQ-W7 for disman-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 23:37:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12426 for ; Mon, 5 Apr 2004 23:37:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAhPN-00021D-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 23:37:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAh1w-0007Co-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 23:13:42 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAgaD-0004Lq-00 for disman-web-archive@ietf.org; Mon, 05 Apr 2004 22:45:02 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAgaF-0004sg-Ef for disman-web-archive@ietf.org; Mon, 05 Apr 2004 22:45:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAgaD-0000BT-Nx; Mon, 05 Apr 2004 22:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAga3-0000Af-69 for disman@optimus.ietf.org; Mon, 05 Apr 2004 22:44:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08364 for ; Mon, 5 Apr 2004 22:44:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAgZz-0004KJ-00 for disman@ietf.org; Mon, 05 Apr 2004 22:44:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAg9d-0001IS-00 for disman@ietf.org; Mon, 05 Apr 2004 22:17:34 -0400 Received: from swan.mail.pas.earthlink.net ([207.217.120.123]) by ietf-mx with esmtp (Exim 4.12) id 1BAfmD-0005yg-00 for disman@ietf.org; Mon, 05 Apr 2004 21:53:21 -0400 Received: from h-68-164-78-136.snvacaid.dynamic.covad.net ([68.164.78.136] helo=oemcomputer) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BAfmD-0000cq-00 for disman@ietf.org; Mon, 05 Apr 2004 18:53:21 -0700 Message-ID: <002401c41b7a$6013ffe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <2147483647.1075035045@[10.1.1.26]> Subject: Re: [Disman] traceroute-mib-2 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: Mon, 5 Apr 2004 18:56:27 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - (as technical contributor - sorry for tardiness in commenting, particularly since the WG chair issued last call *long* ago!) > From: "Juergen Quittek" > To: > Sent: Sunday, January 25, 2004 4:50 AM > Subject: [Disman] traceroute-mib-2 > > 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? ... I *think* the motivation for including zero was to allow this MIB to be used to generate relatively obnoxious test PDUs. (I guess a local LAN device might respond to one of these; RFC 791 sounds like it says that they're supposed to be discarded upon receipt, but I'll leave that to the IP experts. If they are supposed to be discarded, then any device that responds is exhibiting an interesting failure mode. (Would these show up in ifInDiscards?) If they are not supposed to be discarded, then we'd be doubly wrong to exclude the value.) I'm not sure that there is any great value in prohibiting zero, and I'd rather not make changes unless there is clear value in doing so. Randy From disman-admin@ietf.org Wed Apr 14 14:12:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12205 for ; Wed, 14 Apr 2004 14:12:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDok1-00066O-Ff; Wed, 14 Apr 2004 14:04:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDoX0-0002DH-Q2 for disman@optimus.ietf.org; Wed, 14 Apr 2004 13:50:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10713 for ; Wed, 14 Apr 2004 13:50:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDoWy-0003k9-00 for disman@ietf.org; Wed, 14 Apr 2004 13:50:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDoW2-0003dU-00 for disman@ietf.org; Wed, 14 Apr 2004 13:49:38 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDoUt-0003Ul-00 for disman@ietf.org; Wed, 14 Apr 2004 13:48:27 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDoFF-0003jT-25 for disman@ietf.org; Wed, 14 Apr 2004 13:32:17 -0400 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 i3EHVhL03942 for ; Wed, 14 Apr 2004 13:31:43 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Apr 2004 13:31:43 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD340AD3A61D@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Subject: RE: [Disman] My Action Item: Probable Cause Liaison 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: Wed, 14 Apr 2004 13:31:43 -0400 hi I forget, were we planning on sending a response to SG 4 about this? They meet in a couple of weeks. If we do, I might suggest a "Thanks you for the information on your current work related to probable cause. Please keep us informed of your progress". Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Tuesday, March 02, 2004 8:50 PM To: disman@ietf.org Subject: [Disman] My Action Item: Probable Cause Liaison hi I took an action during the disman meeting to send information to the mailing list about how people can find the liaison that was sent from ITU-T SG 4 on the topic of structured probable causes. This work would be of interest if in 5 years time, or whenever, we were looking at an Alarm MIB v2. http://www.ietf.org/IESG/LIAISON/itut-sg4-ls-structured-cause.html Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From exim@www1.ietf.org Wed Apr 14 14:33:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13467 for ; Wed, 14 Apr 2004 14:33:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDp5e-0003sP-P5 for disman-archive@odin.ietf.org; Wed, 14 Apr 2004 14:26:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EIQQBg014897 for disman-archive@odin.ietf.org; Wed, 14 Apr 2004 14:26:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDoth-0000Ue-ER for disman-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 14:14:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12298 for ; Wed, 14 Apr 2004 14:14:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDotf-0005P3-00 for disman-web-archive@ietf.org; Wed, 14 Apr 2004 14:14:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDosj-0005Mh-00 for disman-web-archive@ietf.org; Wed, 14 Apr 2004 14:13:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDorv-0005L7-00 for disman-web-archive@ietf.org; Wed, 14 Apr 2004 14:12:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDok1-00066O-Ff; Wed, 14 Apr 2004 14:04:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDoX0-0002DH-Q2 for disman@optimus.ietf.org; Wed, 14 Apr 2004 13:50:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10713 for ; Wed, 14 Apr 2004 13:50:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDoWy-0003k9-00 for disman@ietf.org; Wed, 14 Apr 2004 13:50:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDoW2-0003dU-00 for disman@ietf.org; Wed, 14 Apr 2004 13:49:38 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDoUt-0003Ul-00 for disman@ietf.org; Wed, 14 Apr 2004 13:48:27 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDoFF-0003jT-25 for disman@ietf.org; Wed, 14 Apr 2004 13:32:17 -0400 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 i3EHVhL03942 for ; Wed, 14 Apr 2004 13:31:43 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Apr 2004 13:31:43 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD340AD3A61D@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Subject: RE: [Disman] My Action Item: Probable Cause Liaison 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, 14 Apr 2004 13:31:43 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 hi I forget, were we planning on sending a response to SG 4 about this? They meet in a couple of weeks. If we do, I might suggest a "Thanks you for the information on your current work related to probable cause. Please keep us informed of your progress". Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Tuesday, March 02, 2004 8:50 PM To: disman@ietf.org Subject: [Disman] My Action Item: Probable Cause Liaison hi I took an action during the disman meeting to send information to the mailing list about how people can find the liaison that was sent from ITU-T SG 4 on the topic of structured probable causes. This work would be of interest if in 5 years time, or whenever, we were looking at an Alarm MIB v2. http://www.ietf.org/IESG/LIAISON/itut-sg4-ls-structured-cause.html Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From disman-admin@ietf.org Mon Apr 26 04:23:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02212 for ; Mon, 26 Apr 2004 04:23:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1KR-0001wz-In; Mon, 26 Apr 2004 04:19:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1IM-0001On-BW for disman@optimus.ietf.org; Mon, 26 Apr 2004 04:16:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01960 for ; Mon, 26 Apr 2004 04:16:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI1IJ-0001j1-IM for disman@ietf.org; Mon, 26 Apr 2004 04:16:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI1HQ-0001Wj-00 for disman@ietf.org; Mon, 26 Apr 2004 04:15:57 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BI1Gv-0001JF-00; Mon, 26 Apr 2004 04:15:25 -0400 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 i3Q8Eqrm005294; Mon, 26 Apr 2004 10:14:55 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i3Q8BCQo004861; Mon, 26 Apr 2004 10:11:12 +0200 (CEST) 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 i3Q8BBri004859; Mon, 26 Apr 2004 10:11:12 +0200 (CEST) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 640BE123451; Mon, 26 Apr 2004 10:11:10 +0200 (CEST) From: Juergen Quittek To: Eduardo Cardona , Randy Presuhn , disman@ietf.org Cc: "Ipcdn List (E-mail)" Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Message-ID: <2147483647.1082974262@[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 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, 26 Apr 2004 10:11:02 +0200 Content-Transfer-Encoding: 7bit Eduardo, Thank you for raising this issue and my apologies for this very late reply. I ran into similar problems several times where a well designed technology was too mighty or too general for being implemented at small devices. Your suggestions aim at introducing additional MODULE-COMPLIANCE clauses to the PING-MIB, the TRACEROUTE-MIB and LOOKUP-MIB modules for allowing simpler implementations with smaller footprints. I support your proposal, but have a few comments, see below. I am willing to make suggestions for minimalCompliance clauses for the MIB modules, but first the WG should agree on two issues: - Is it agreed to add such clauses, that definitely require less funtionality to be implemented? - what is the preferred procedure for columnar objects that are not required for minimal compliancy? We can either allow them to be missing completely. But this would result in non-consecutive numbering of the remaining objects in the minimal tables. Or we require them to be implemented as read-only indicating that the feature that they would serve in full compliancy is not supported. Please find further comments inline. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 02.03.2004 10:04 h -0700 Eduardo Cardona wrote: > Randy, > > Few comments, > > I review the MIB and appears compelling respect to previous RFC > > Just one comment > > > (*) traceRouteCtlMiscOptions > It appears to me an uncanny object and rather implementations may opt to > extend the capabilities in the private branch, could leave with that to > avoid deprecation, of if there are field implementations. Currently, the MODULE-COMPLIANCE clause traceRouteCompliance requests implementation of this object, but it may be implemented as read-only and returning always a value of zero, if there is not further semantics defined for it. Do you suggest to completely remove the object or to state in the MODULE-COMPLIANCE clause that it does not need to be implemented? > Regardless of the additions to the MIB I apologize for the late notice, > > Before sending a complete proposal and get your concept of the best > approach, below is the proposal to add a simplified Compliance > statement for devices not requiring to keep constant status of > PING/TRACEROUTE operations, only remote operation per operator request. > > > We are looking at your comments about the clear overlap in > draft-ietf-disman-remops-mib-v2-01.txt > With IPCDN draft > http://www.ipcdn.org/drafts/draft-ietf-ipcdn-cable-gateway-tools-mib-00. > txt ( currently out of date in IETF drafts site) which is clearly a > subset of the DISMAN-PING-MIB > Lectors refer to > http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg00818. > html > > Should the proposal below being include in the remops MIB or should we > update IPCDN cable gateway Tools MIB module to be just the compliance > statement outlined below? I doubt that it is a good idea to replicate large portions of the PING-MIB in the IPCDN cable gateway Tools MIB module, as it is done right now. > RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null named > log" default entry for devices not supporting the named log > Named log is analog to disman remops draft for "OwnerIndex" and > "TestName" where default entries are created > (null owner, null TestName) for a manager requested operation of PING/ > TRACEROUTE, NSLOOKUP, mostly for small foot-print devices with no > network monitoring role at the connectivity level as pretended with this > updated RFC. I don't think the remops MIB modules forbid null-named entries in the respective tables. But currently the support of a read-write pingCtlRowStatus is mandatory. Is your concrete suggestion to add something like OBJECT XXRowStatus MIN-ACCESS read-only DESCRIPTION "Implementations may disallow the creation of named entries." with XX=pingCtl,traceRouteCtl,lookupCtl? > In summary A new Compliance Statement for small devices with no > monitoring capabilities to : > 1) remove the constant pulling and login information > 2) remove the test row creation > - CTL* Results* tables only default entries (null owner, null > TestName) > 3) History* tables not required. > - New basicGroups to exclude History* objects and other objects > which are not relevant to the simplified > system. > - Create an additional set of Compliance statements to require the > new Groups and other objects Compliance > requirements MIN-ACCESS clauses mainly > > Schema of the content of the new Compliance statement: > > List of objects not to include in basicPingGroup OBJECT-GROUP clause > qnd/or hints for OBJECT Compliances: > pingMaxConcurrentRequests -- remove Could also be read-only returning 1. > pingCtlDataFill -- remove or MIN-ACCESS read-only default > value is OK > pingCtlFrequency -- remove Only one test Could also be read-only returning 0. > pingCtlType -- remove or MIN-ACCESS read-only > pingCtlByPassRouteTable -- remove or MIN-ACCESS read-only > pingCtlDSField -- MIN-ACCESS read-only > pingCtlStorageType -- remove > pingCtlRowStatus -- SYNTAX RowStatus (notReady(2) > WRITE-SYNTAX RowStatus (active(1), notInService(3) Why don't you consider removing this object? > pingCtlIfIndex -- not to include > pingProbeHistory* -- not to include. > > List of objects not to include in basicTraceRouteGroup OBJECT-GROUP > clause and/or hints for OBJECT Compliances: > traceRouteMaxConcurrentRequests -- remove > traceRouteCtlType -- remove or MIN-ACCESS read-only > traceRouteCtlDSField -- MIN-ACCESS read-only > traceRouteCtlByPassRouteTable -- remove or MIN-ACCESS read-only > traceRouteCtlIfIndex -- not to include > traceRouteCtlMiscOptions -- not to include > traceRouteCtlDontFragment -- remove or MIN-ACCESS read-only > traceRouteCtlInitialTtl -- remove or MIN-ACCESS > traceRouteCtlFrequency -- remove only one test > traceRouteCtlDescr -- remove > traceRouteCtlCreateHopsEntries -- remove HopsEntries not required. > traceRouteCtlRowStatus -- SYNTAX RowStatus (notReady(2) > WRITE-SYNTAX RowStatus (active(1), notInService(3) > traceRouteCtlStorageType -- remove > traceRouteProbeHistory* -- not to include. > > List of objects not to include in basicLookupGroup OBJECT-GROUP clause > and/or hints for OBJECT Compliances: > lookupMaxConcurrentRequests -- remove > lookupPurgeTime -- remove > lookupCtlRowStatus -- SYNTAX RowStatus (notReady(2) > WRITE-SYNTAX RowStatus (active(1), notInService(3) > > > Best Regards > > Eduardo > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Monday, March 01, 2004 6:44 PM > To: disman@ietf.org > Subject: RE: [Disman] WG last call on > draft-ietf-disman-remops-mib-v2-01.txt > > > > Hi - > >> From: Eduardo Cardona >> Sent: Mar 2, 2004 9:25 AM >> To: Randy Presuhn , disman@ietf.org >> Subject: RE: [Disman] WG last call on >> draft-ietf-disman-remops-mib-v2-01.txt > ... >> One simple note, I tough last call was March 5th > > No, it was supposed to end March 2. However, I'm not > going to hand it to our AD until I can be reasonably sure > that it has received adequate review. > >> We at Cablelabs are interested in adding a simplified compliance >> statement for ad-hoc procedure call instead of a user entry schecule >> entry, so an user can do a one time execution e.g PING > > It would have been nice to have learned of this earlier, rather than > during WG last call. > >> The draft we had is almost complete, >> Would be that an opportunity to add that? I can post that tomorrow in >> the list if compeling > ... > > I'd like to have this discussion sooner rather than later, so please > make > your specific proposal as quickly as you can. My opinion as a technical > contributor is that the case for these changes would need to be fairly > compelling if they would result in the remote operations MIB cycling > at proposed rather than advancing to draft standard. As working group > chair, I want to ensure that whatever course we take reflects WG > consensus. So, balancing the need for bringing this to a conclusion > with > the need to ensure that the technical issues are properly considered, > I'll entertain discussion of this issue ("ad hoc procedure call") until > Friday noon (Korean Time). Shortly thereafter I'll make a call on > whether there is consensus to modify the draft regarding this specific > proposal. > > Randy > > > From exim@www1.ietf.org Mon Apr 26 04:33:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02982 for ; Mon, 26 Apr 2004 04:33:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1UD-0004cz-EA for disman-archive@odin.ietf.org; Mon, 26 Apr 2004 04:29:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q8T9K2017790 for disman-archive@odin.ietf.org; Mon, 26 Apr 2004 04:29:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1Q1-0003Mk-9j for disman-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 04:24:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02375 for ; Mon, 26 Apr 2004 04:24:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI1Py-0003Li-GV for disman-web-archive@ietf.org; Mon, 26 Apr 2004 04:24:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI1P4-00038Z-00 for disman-web-archive@ietf.org; Mon, 26 Apr 2004 04:23:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI1OB-0002vN-00 for disman-web-archive@ietf.org; Mon, 26 Apr 2004 04:22:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1KR-0001wz-In; Mon, 26 Apr 2004 04:19:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1IM-0001On-BW for disman@optimus.ietf.org; Mon, 26 Apr 2004 04:16:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01960 for ; Mon, 26 Apr 2004 04:16:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI1IJ-0001j1-IM for disman@ietf.org; Mon, 26 Apr 2004 04:16:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI1HQ-0001Wj-00 for disman@ietf.org; Mon, 26 Apr 2004 04:15:57 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BI1Gv-0001JF-00; Mon, 26 Apr 2004 04:15:25 -0400 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 i3Q8Eqrm005294; Mon, 26 Apr 2004 10:14:55 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i3Q8BCQo004861; Mon, 26 Apr 2004 10:11:12 +0200 (CEST) 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 i3Q8BBri004859; Mon, 26 Apr 2004 10:11:12 +0200 (CEST) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 640BE123451; Mon, 26 Apr 2004 10:11:10 +0200 (CEST) From: Juergen Quittek To: Eduardo Cardona , Randy Presuhn , disman@ietf.org Cc: "Ipcdn List (E-mail)" Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Message-ID: <2147483647.1082974262@[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 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, 26 Apr 2004 10:11:02 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eduardo, Thank you for raising this issue and my apologies for this very late reply. I ran into similar problems several times where a well designed technology was too mighty or too general for being implemented at small devices. Your suggestions aim at introducing additional MODULE-COMPLIANCE clauses to the PING-MIB, the TRACEROUTE-MIB and LOOKUP-MIB modules for allowing simpler implementations with smaller footprints. I support your proposal, but have a few comments, see below. I am willing to make suggestions for minimalCompliance clauses for the MIB modules, but first the WG should agree on two issues: - Is it agreed to add such clauses, that definitely require less funtionality to be implemented? - what is the preferred procedure for columnar objects that are not required for minimal compliancy? We can either allow them to be missing completely. But this would result in non-consecutive numbering of the remaining objects in the minimal tables. Or we require them to be implemented as read-only indicating that the feature that they would serve in full compliancy is not supported. Please find further comments inline. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 02.03.2004 10:04 h -0700 Eduardo Cardona wrote: > Randy, > > Few comments, > > I review the MIB and appears compelling respect to previous RFC > > Just one comment > > > (*) traceRouteCtlMiscOptions > It appears to me an uncanny object and rather implementations may opt to > extend the capabilities in the private branch, could leave with that to > avoid deprecation, of if there are field implementations. Currently, the MODULE-COMPLIANCE clause traceRouteCompliance requests implementation of this object, but it may be implemented as read-only and returning always a value of zero, if there is not further semantics defined for it. Do you suggest to completely remove the object or to state in the MODULE-COMPLIANCE clause that it does not need to be implemented? > Regardless of the additions to the MIB I apologize for the late notice, > > Before sending a complete proposal and get your concept of the best > approach, below is the proposal to add a simplified Compliance > statement for devices not requiring to keep constant status of > PING/TRACEROUTE operations, only remote operation per operator request. > > > We are looking at your comments about the clear overlap in > draft-ietf-disman-remops-mib-v2-01.txt > With IPCDN draft > http://www.ipcdn.org/drafts/draft-ietf-ipcdn-cable-gateway-tools-mib-00. > txt ( currently out of date in IETF drafts site) which is clearly a > subset of the DISMAN-PING-MIB > Lectors refer to > http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg00818. > html > > Should the proposal below being include in the remops MIB or should we > update IPCDN cable gateway Tools MIB module to be just the compliance > statement outlined below? I doubt that it is a good idea to replicate large portions of the PING-MIB in the IPCDN cable gateway Tools MIB module, as it is done right now. > RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null named > log" default entry for devices not supporting the named log > Named log is analog to disman remops draft for "OwnerIndex" and > "TestName" where default entries are created > (null owner, null TestName) for a manager requested operation of PING/ > TRACEROUTE, NSLOOKUP, mostly for small foot-print devices with no > network monitoring role at the connectivity level as pretended with this > updated RFC. I don't think the remops MIB modules forbid null-named entries in the respective tables. But currently the support of a read-write pingCtlRowStatus is mandatory. Is your concrete suggestion to add something like OBJECT XXRowStatus MIN-ACCESS read-only DESCRIPTION "Implementations may disallow the creation of named entries." with XX=pingCtl,traceRouteCtl,lookupCtl? > In summary A new Compliance Statement for small devices with no > monitoring capabilities to : > 1) remove the constant pulling and login information > 2) remove the test row creation > - CTL* Results* tables only default entries (null owner, null > TestName) > 3) History* tables not required. > - New basicGroups to exclude History* objects and other objects > which are not relevant to the simplified > system. > - Create an additional set of Compliance statements to require the > new Groups and other objects Compliance > requirements MIN-ACCESS clauses mainly > > Schema of the content of the new Compliance statement: > > List of objects not to include in basicPingGroup OBJECT-GROUP clause > qnd/or hints for OBJECT Compliances: > pingMaxConcurrentRequests -- remove Could also be read-only returning 1. > pingCtlDataFill -- remove or MIN-ACCESS read-only default > value is OK > pingCtlFrequency -- remove Only one test Could also be read-only returning 0. > pingCtlType -- remove or MIN-ACCESS read-only > pingCtlByPassRouteTable -- remove or MIN-ACCESS read-only > pingCtlDSField -- MIN-ACCESS read-only > pingCtlStorageType -- remove > pingCtlRowStatus -- SYNTAX RowStatus (notReady(2) > WRITE-SYNTAX RowStatus (active(1), notInService(3) Why don't you consider removing this object? > pingCtlIfIndex -- not to include > pingProbeHistory* -- not to include. > > List of objects not to include in basicTraceRouteGroup OBJECT-GROUP > clause and/or hints for OBJECT Compliances: > traceRouteMaxConcurrentRequests -- remove > traceRouteCtlType -- remove or MIN-ACCESS read-only > traceRouteCtlDSField -- MIN-ACCESS read-only > traceRouteCtlByPassRouteTable -- remove or MIN-ACCESS read-only > traceRouteCtlIfIndex -- not to include > traceRouteCtlMiscOptions -- not to include > traceRouteCtlDontFragment -- remove or MIN-ACCESS read-only > traceRouteCtlInitialTtl -- remove or MIN-ACCESS > traceRouteCtlFrequency -- remove only one test > traceRouteCtlDescr -- remove > traceRouteCtlCreateHopsEntries -- remove HopsEntries not required. > traceRouteCtlRowStatus -- SYNTAX RowStatus (notReady(2) > WRITE-SYNTAX RowStatus (active(1), notInService(3) > traceRouteCtlStorageType -- remove > traceRouteProbeHistory* -- not to include. > > List of objects not to include in basicLookupGroup OBJECT-GROUP clause > and/or hints for OBJECT Compliances: > lookupMaxConcurrentRequests -- remove > lookupPurgeTime -- remove > lookupCtlRowStatus -- SYNTAX RowStatus (notReady(2) > WRITE-SYNTAX RowStatus (active(1), notInService(3) > > > Best Regards > > Eduardo > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Monday, March 01, 2004 6:44 PM > To: disman@ietf.org > Subject: RE: [Disman] WG last call on > draft-ietf-disman-remops-mib-v2-01.txt > > > > Hi - > >> From: Eduardo Cardona >> Sent: Mar 2, 2004 9:25 AM >> To: Randy Presuhn , disman@ietf.org >> Subject: RE: [Disman] WG last call on >> draft-ietf-disman-remops-mib-v2-01.txt > ... >> One simple note, I tough last call was March 5th > > No, it was supposed to end March 2. However, I'm not > going to hand it to our AD until I can be reasonably sure > that it has received adequate review. > >> We at Cablelabs are interested in adding a simplified compliance >> statement for ad-hoc procedure call instead of a user entry schecule >> entry, so an user can do a one time execution e.g PING > > It would have been nice to have learned of this earlier, rather than > during WG last call. > >> The draft we had is almost complete, >> Would be that an opportunity to add that? I can post that tomorrow in >> the list if compeling > ... > > I'd like to have this discussion sooner rather than later, so please > make > your specific proposal as quickly as you can. My opinion as a technical > contributor is that the case for these changes would need to be fairly > compelling if they would result in the remote operations MIB cycling > at proposed rather than advancing to draft standard. As working group > chair, I want to ensure that whatever course we take reflects WG > consensus. So, balancing the need for bringing this to a conclusion > with > the need to ensure that the technical issues are properly considered, > I'll entertain discussion of this issue ("ad hoc procedure call") until > Friday noon (Korean Time). Shortly thereafter I'll make a call on > whether there is consensus to modify the draft regarding this specific > proposal. > > Randy > > > From disman-admin@ietf.org Mon Apr 26 10:34:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24398 for ; Mon, 26 Apr 2004 10:34:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI74X-0000D0-53; Mon, 26 Apr 2004 10:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6wq-0005r3-5k for disman@optimus.ietf.org; Mon, 26 Apr 2004 10:19:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23215 for ; Mon, 26 Apr 2004 10:19:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI6wn-0002GJ-Py for disman@ietf.org; Mon, 26 Apr 2004 10:19:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI6w6-0002DI-00 for disman@ietf.org; Mon, 26 Apr 2004 10:18:20 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BI6v8-00024E-00; Mon, 26 Apr 2004 10:17:18 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i3QEGdGe018712; Mon, 26 Apr 2004 08:16:39 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Message-ID: <5259D0D7419C6149B347837A2E64F46F03E264@srvxchg.cablelabs.com> Thread-Topic: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Thread-Index: AcQrZpSh6AQwB7tLRNuaiutocT3fSQAIi1DA From: "Eduardo Cardona" To: "Juergen Quittek" , "Randy Presuhn" , Cc: "Ipcdn List (E-mail)" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 08:16:39 -0600 Content-Transfer-Encoding: quoted-printable Jurgen,=20 Thanks for your reply, See comments below and inline -----Original Message----- From: Juergen Quittek [mailto:quittek@ccrle.nec.de]=20 Sent: Monday, April 26, 2004 2:11 AM To: Eduardo Cardona; Randy Presuhn; disman@ietf.org Cc: Ipcdn List (E-mail) Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Eduardo, Thank you for raising this issue and my apologies for this very late reply. I ran into similar problems several times where a well designed technology was too mighty or too general for being implemented at small devices. Your suggestions aim at introducing additional MODULE-COMPLIANCE clauses to the PING-MIB, the TRACEROUTE-MIB and LOOKUP-MIB modules for allowing simpler implementations with smaller footprints. I support your proposal, but have a few comments, see below. I am willing to make suggestions for minimalCompliance clauses for the MIB modules, but first the WG should agree on two issues: - Is it agreed to add such clauses, that definitely require less funtionality to be implemented? - what is the preferred procedure for columnar objects that are not required for minimal compliancy? We can either allow them to be missing completely. But this would result in non-consecutive numbering of the remaining objects in the minimal tables. Or we require them to be implemented as read-only indicating that the feature that they would serve in full compliancy is not supported. I understand the desire of having normalized process and applications that may tune themselves by just reading static values (read-write with read-only compliances) as a subset of the full module compliance It is also understood that some vendors later may complain of 'static' requirements as a waist of resources in terms of memory and code. Just my note in the disjunctive of the implementer vs the manager approaches. I always though the AGENT-CAPABILLITIES is the best tool for minimize devices implementations plus adding a robust layer in the manager side to create the vendor, compliance/specific "what if cases", but not very used I guess by current tools. We Will be ok with the disman group decision in this matter, =20 =20 Please find further comments inline. Juergen --=20 Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 02.03.2004 10:04 h -0700 Eduardo Cardona wrote: > Randy, > > Few comments, > > I review the MIB and appears compelling respect to previous RFC > > Just one comment > > > (*) traceRouteCtlMiscOptions > It appears to me an uncanny object and rather implementations may opt=20 > to extend the capabilities in the private branch, could leave with=20 > that to avoid deprecation, of if there are field implementations. Currently, the MODULE-COMPLIANCE clause traceRouteCompliance requests implementation of this object, but it may be implemented as read-only and returning always a value of zero, if there is not further semantics defined for it. Do you suggest to completely remove the object or to state in the MODULE-COMPLIANCE clause that it does not need to be implemented? I see more an augmentation or RowPointer to an enterprise MIB subtree (from the POV of OPS MIB guidelines, and flexible enough for vendor extensions); which may imply deprecation and a new object for the RowPointer case. I just noted that "opaque" objects are not very common in new MIBs, Can go either with read-only or deprecation. > Regardless of the additions to the MIB I apologize for the late=20 > notice, > > Before sending a complete proposal and get your concept of the best=20 > approach, below is the proposal to add a simplified Compliance=20 > statement for devices not requiring to keep constant status of=20 > PING/TRACEROUTE operations, only remote operation per operator=20 > request. > > > We are looking at your comments about the clear overlap in=20 > draft-ietf-disman-remops-mib-v2-01.txt > With IPCDN draft=20 > http://www.ipcdn.org/drafts/draft-ietf-ipcdn-cable-gateway-tools-mib-0 > 0. > txt ( currently out of date in IETF drafts site) which is clearly a > subset of the DISMAN-PING-MIB > Lectors refer to > http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg00818. > html > > Should the proposal below being include in the remops MIB or should we > update IPCDN cable gateway Tools MIB module to be just the compliance=20 > statement outlined below? I doubt that it is a good idea to replicate large portions of the PING-MIB in the IPCDN cable gateway Tools MIB module, as it is done right now. The question was really if=20 The PING-MIB is changed to just define a 'minimalCompliance' for IPCDN cable Gateway Or draft-ietf-disman-remops-mib-v2-01.txt will include the 'minimalCompliance' Not to continue the MIB module overlapping. > RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null=20 > named log" default entry for devices not supporting the named log=20 > Named log is analog to disman remops draft for "OwnerIndex" and=20 > "TestName" where default entries are created (null owner, null=20 > TestName) for a manager requested operation of PING/ TRACEROUTE,=20 > NSLOOKUP, mostly for small foot-print devices with no network=20 > monitoring role at the connectivity level as pretended with this=20 > updated RFC. I don't think the remops MIB modules forbid null-named entries in the respective tables. But currently the support of a read-write pingCtlRowStatus is mandatory. Is your concrete suggestion to add something like OBJECT XXRowStatus MIN-ACCESS read-only DESCRIPTION "Implementations may disallow the creation of named entries." with XX=3DpingCtl,traceRouteCtl,lookupCtl? I agree it does not prohibit the nul entry, Just for the minumal compliance no need to 'create' the null entry any time - Just a default entry - , then the read-only complience will be ok The only question remaining in our side is: 1) If RowStatus NotReady will be an indication that not all needed parameters ( Dest Addr) are propoerly setup(?) Or=20 2) The pingCtlAdminStatus Description may need an error code for both Full compliance and minimal compliance to address the SNMP SET when the entry is 'notReady'. Something around:=20 "... returns error 'inconsistentVelue'/'wrongValue' -Advice?- when trying to set to 'enabled' if not previously specified a valid pingCtlTargetAddress" =20 The last onr (2) I think will be enough for removing RowStatus in the minimal Compliance ( not include object in the minimal group) or define it as read-only SYNTAX > In summary A new Compliance Statement for small devices with no=20 > monitoring capabilities to : > 1) remove the constant pulling and login information > 2) remove the test row creation > - CTL* Results* tables only default entries (null owner, null > TestName) > 3) History* tables not required. > - New basicGroups to exclude History* objects and other objects which=20 > are not relevant to the simplified > system. > - Create an additional set of Compliance statements to require=20 > the new Groups and other objects Compliance > requirements MIN-ACCESS clauses mainly > > Schema of the content of the new Compliance statement: > > List of objects not to include in basicPingGroup OBJECT-GROUP clause=20 > qnd/or hints for OBJECT Compliances: > pingMaxConcurrentRequests -- remove Could also be read-only returning 1. Agree... > pingCtlDataFill -- remove or MIN-ACCESS read-only default > value is OK > pingCtlFrequency -- remove Only one test Could also be read-only returning 0. Agree... > pingCtlType -- remove or MIN-ACCESS read-only > pingCtlByPassRouteTable -- remove or MIN-ACCESS read-only > pingCtlDSField -- MIN-ACCESS read-only > pingCtlStorageType -- remove > pingCtlRowStatus -- SYNTAX RowStatus (notReady(2) > WRITE-SYNTAX RowStatus (active(1), notInService(3) Agree... See more for pingCtlAdminStatus above =20 Why don't you consider removing this object? > pingCtlIfIndex -- not to include > pingProbeHistory* -- not to include. > > List of objects not to include in basicTraceRouteGroup OBJECT-GROUP=20 > clause and/or hints for OBJECT Compliances: > traceRouteMaxConcurrentRequests -- remove > traceRouteCtlType -- remove or MIN-ACCESS read-only > traceRouteCtlDSField -- MIN-ACCESS read-only > traceRouteCtlByPassRouteTable -- remove or MIN-ACCESS read-only > traceRouteCtlIfIndex -- not to include > traceRouteCtlMiscOptions -- not to include > traceRouteCtlDontFragment -- remove or MIN-ACCESS read-only > traceRouteCtlInitialTtl -- remove or MIN-ACCESS > traceRouteCtlFrequency -- remove only one test > traceRouteCtlDescr -- remove > traceRouteCtlCreateHopsEntries -- remove HopsEntries not required. > traceRouteCtlRowStatus -- SYNTAX RowStatus (notReady(2) > WRITE-SYNTAX RowStatus (active(1), notInService(3) > traceRouteCtlStorageType -- remove > traceRouteProbeHistory* -- not to include. > > List of objects not to include in basicLookupGroup OBJECT-GROUP=20 > clause and/or hints for OBJECT Compliances: > lookupMaxConcurrentRequests -- remove > lookupPurgeTime -- remove > lookupCtlRowStatus -- SYNTAX RowStatus (notReady(2) > WRITE-SYNTAX RowStatus (active(1), notInService(3) > > > Best Regards > > Eduardo > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Monday, March 01, 2004 6:44 PM > To: disman@ietf.org > Subject: RE: [Disman] WG last call on=20 > draft-ietf-disman-remops-mib-v2-01.txt > > > > Hi - > >> From: Eduardo Cardona >> Sent: Mar 2, 2004 9:25 AM >> To: Randy Presuhn , disman@ietf.org >> Subject: RE: [Disman] WG last call on=20 >> draft-ietf-disman-remops-mib-v2-01.txt > ... >> One simple note, I tough last call was March 5th > > No, it was supposed to end March 2. However, I'm not > going to hand it to our AD until I can be reasonably sure that it has=20 > received adequate review. > >> We at Cablelabs are interested in adding a simplified compliance=20 >> statement for ad-hoc procedure call instead of a user entry schecule=20 >> entry, so an user can do a one time execution e.g PING > > It would have been nice to have learned of this earlier, rather than=20 > during WG last call. > >> The draft we had is almost complete, >> Would be that an opportunity to add that? I can post that tomorrow in >> the list if compeling > ... > > I'd like to have this discussion sooner rather than later, so please=20 > make your specific proposal as quickly as you can. My opinion as a=20 > technical contributor is that the case for these changes would need to > be fairly compelling if they would result in the remote operations MIB > cycling at proposed rather than advancing to draft standard. As=20 > working group chair, I want to ensure that whatever course we take=20 > reflects WG consensus. So, balancing the need for bringing this to a=20 > conclusion with > the need to ensure that the technical issues are properly considered, > I'll entertain discussion of this issue ("ad hoc procedure call") until > Friday noon (Korean Time). Shortly thereafter I'll make a call on > whether there is consensus to modify the draft regarding this specific > proposal. > > Randy > > > From exim@www1.ietf.org Mon Apr 26 10:48:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25104 for ; Mon, 26 Apr 2004 10:48:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7Gf-0003xe-Mc for disman-archive@odin.ietf.org; Mon, 26 Apr 2004 10:39:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QEdXHA015222 for disman-archive@odin.ietf.org; Mon, 26 Apr 2004 10:39:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7DA-0002Rd-DV for disman-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 10:35:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24512 for ; Mon, 26 Apr 2004 10:35:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI7D7-0003Dm-Vy for disman-web-archive@ietf.org; Mon, 26 Apr 2004 10:35:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI7CC-0003Bk-00 for disman-web-archive@ietf.org; Mon, 26 Apr 2004 10:34:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI7BS-00039x-00 for disman-web-archive@ietf.org; Mon, 26 Apr 2004 10:34:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI74X-0000D0-53; Mon, 26 Apr 2004 10:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6wq-0005r3-5k for disman@optimus.ietf.org; Mon, 26 Apr 2004 10:19:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23215 for ; Mon, 26 Apr 2004 10:19:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI6wn-0002GJ-Py for disman@ietf.org; Mon, 26 Apr 2004 10:19:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI6w6-0002DI-00 for disman@ietf.org; Mon, 26 Apr 2004 10:18:20 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BI6v8-00024E-00; Mon, 26 Apr 2004 10:17:18 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i3QEGdGe018712; Mon, 26 Apr 2004 08:16:39 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Message-ID: <5259D0D7419C6149B347837A2E64F46F03E264@srvxchg.cablelabs.com> Thread-Topic: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Thread-Index: AcQrZpSh6AQwB7tLRNuaiutocT3fSQAIi1DA From: "Eduardo Cardona" To: "Juergen Quittek" , "Randy Presuhn" , Cc: "Ipcdn List (E-mail)" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 08:16:39 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jurgen,=20 Thanks for your reply, See comments below and inline -----Original Message----- From: Juergen Quittek [mailto:quittek@ccrle.nec.de]=20 Sent: Monday, April 26, 2004 2:11 AM To: Eduardo Cardona; Randy Presuhn; disman@ietf.org Cc: Ipcdn List (E-mail) Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Eduardo, Thank you for raising this issue and my apologies for this very late reply. I ran into similar problems several times where a well designed technology was too mighty or too general for being implemented at small devices. Your suggestions aim at introducing additional MODULE-COMPLIANCE clauses to the PING-MIB, the TRACEROUTE-MIB and LOOKUP-MIB modules for allowing simpler implementations with smaller footprints. I support your proposal, but have a few comments, see below. I am willing to make suggestions for minimalCompliance clauses for the MIB modules, but first the WG should agree on two issues: - Is it agreed to add such clauses, that definitely require less funtionality to be implemented? - what is the preferred procedure for columnar objects that are not required for minimal compliancy? We can either allow them to be missing completely. But this would result in non-consecutive numbering of the remaining objects in the minimal tables. Or we require them to be implemented as read-only indicating that the feature that they would serve in full compliancy is not supported. I understand the desire of having normalized process and applications that may tune themselves by just reading static values (read-write with read-only compliances) as a subset of the full module compliance It is also understood that some vendors later may complain of 'static' requirements as a waist of resources in terms of memory and code. Just my note in the disjunctive of the implementer vs the manager approaches. I always though the AGENT-CAPABILLITIES is the best tool for minimize devices implementations plus adding a robust layer in the manager side to create the vendor, compliance/specific "what if cases", but not very used I guess by current tools. We Will be ok with the disman group decision in this matter, =20 =20 Please find further comments inline. Juergen --=20 Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 02.03.2004 10:04 h -0700 Eduardo Cardona wrote: > Randy, > > Few comments, > > I review the MIB and appears compelling respect to previous RFC > > Just one comment > > > (*) traceRouteCtlMiscOptions > It appears to me an uncanny object and rather implementations may opt=20 > to extend the capabilities in the private branch, could leave with=20 > that to avoid deprecation, of if there are field implementations. Currently, the MODULE-COMPLIANCE clause traceRouteCompliance requests implementation of this object, but it may be implemented as read-only and returning always a value of zero, if there is not further semantics defined for it. Do you suggest to completely remove the object or to state in the MODULE-COMPLIANCE clause that it does not need to be implemented? I see more an augmentation or RowPointer to an enterprise MIB subtree (from the POV of OPS MIB guidelines, and flexible enough for vendor extensions); which may imply deprecation and a new object for the RowPointer case. I just noted that "opaque" objects are not very common in new MIBs, Can go either with read-only or deprecation. > Regardless of the additions to the MIB I apologize for the late=20 > notice, > > Before sending a complete proposal and get your concept of the best=20 > approach, below is the proposal to add a simplified Compliance=20 > statement for devices not requiring to keep constant status of=20 > PING/TRACEROUTE operations, only remote operation per operator=20 > request. > > > We are looking at your comments about the clear overlap in=20 > draft-ietf-disman-remops-mib-v2-01.txt > With IPCDN draft=20 > http://www.ipcdn.org/drafts/draft-ietf-ipcdn-cable-gateway-tools-mib-0 > 0. > txt ( currently out of date in IETF drafts site) which is clearly a > subset of the DISMAN-PING-MIB > Lectors refer to > http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg00818. > html > > Should the proposal below being include in the remops MIB or should we > update IPCDN cable gateway Tools MIB module to be just the compliance=20 > statement outlined below? I doubt that it is a good idea to replicate large portions of the PING-MIB in the IPCDN cable gateway Tools MIB module, as it is done right now. The question was really if=20 The PING-MIB is changed to just define a 'minimalCompliance' for IPCDN cable Gateway Or draft-ietf-disman-remops-mib-v2-01.txt will include the 'minimalCompliance' Not to continue the MIB module overlapping. > RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null=20 > named log" default entry for devices not supporting the named log=20 > Named log is analog to disman remops draft for "OwnerIndex" and=20 > "TestName" where default entries are created (null owner, null=20 > TestName) for a manager requested operation of PING/ TRACEROUTE,=20 > NSLOOKUP, mostly for small foot-print devices with no network=20 > monitoring role at the connectivity level as pretended with this=20 > updated RFC. I don't think the remops MIB modules forbid null-named entries in the respective tables. But currently the support of a read-write pingCtlRowStatus is mandatory. Is your concrete suggestion to add something like OBJECT XXRowStatus MIN-ACCESS read-only DESCRIPTION "Implementations may disallow the creation of named entries." with XX=3DpingCtl,traceRouteCtl,lookupCtl? I agree it does not prohibit the nul entry, Just for the minumal compliance no need to 'create' the null entry any time - Just a default entry - , then the read-only complience will be ok The only question remaining in our side is: 1) If RowStatus NotReady will be an indication that not all needed parameters ( Dest Addr) are propoerly setup(?) Or=20 2) The pingCtlAdminStatus Description may need an error code for both Full compliance and minimal compliance to address the SNMP SET when the entry is 'notReady'. Something around:=20 "... returns error 'inconsistentVelue'/'wrongValue' -Advice?- when trying to set to 'enabled' if not previously specified a valid pingCtlTargetAddress" =20 The last onr (2) I think will be enough for removing RowStatus in the minimal Compliance ( not include object in the minimal group) or define it as read-only SYNTAX > In summary A new Compliance Statement for small devices with no=20 > monitoring capabilities to : > 1) remove the constant pulling and login information > 2) remove the test row creation > - CTL* Results* tables only default entries (null owner, null > TestName) > 3) History* tables not required. > - New basicGroups to exclude History* objects and other objects which=20 > are not relevant to the simplified > system. > - Create an additional set of Compliance statements to require=20 > the new Groups and other objects Compliance > requirements MIN-ACCESS clauses mainly > > Schema of the content of the new Compliance statement: > > List of objects not to include in basicPingGroup OBJECT-GROUP clause=20 > qnd/or hints for OBJECT Compliances: > pingMaxConcurrentRequests -- remove Could also be read-only returning 1. Agree... > pingCtlDataFill -- remove or MIN-ACCESS read-only default > value is OK > pingCtlFrequency -- remove Only one test Could also be read-only returning 0. Agree... > pingCtlType -- remove or MIN-ACCESS read-only > pingCtlByPassRouteTable -- remove or MIN-ACCESS read-only > pingCtlDSField -- MIN-ACCESS read-only > pingCtlStorageType -- remove > pingCtlRowStatus -- SYNTAX RowStatus (notReady(2) > WRITE-SYNTAX RowStatus (active(1), notInService(3) Agree... See more for pingCtlAdminStatus above =20 Why don't you consider removing this object? > pingCtlIfIndex -- not to include > pingProbeHistory* -- not to include. > > List of objects not to include in basicTraceRouteGroup OBJECT-GROUP=20 > clause and/or hints for OBJECT Compliances: > traceRouteMaxConcurrentRequests -- remove > traceRouteCtlType -- remove or MIN-ACCESS read-only > traceRouteCtlDSField -- MIN-ACCESS read-only > traceRouteCtlByPassRouteTable -- remove or MIN-ACCESS read-only > traceRouteCtlIfIndex -- not to include > traceRouteCtlMiscOptions -- not to include > traceRouteCtlDontFragment -- remove or MIN-ACCESS read-only > traceRouteCtlInitialTtl -- remove or MIN-ACCESS > traceRouteCtlFrequency -- remove only one test > traceRouteCtlDescr -- remove > traceRouteCtlCreateHopsEntries -- remove HopsEntries not required. > traceRouteCtlRowStatus -- SYNTAX RowStatus (notReady(2) > WRITE-SYNTAX RowStatus (active(1), notInService(3) > traceRouteCtlStorageType -- remove > traceRouteProbeHistory* -- not to include. > > List of objects not to include in basicLookupGroup OBJECT-GROUP=20 > clause and/or hints for OBJECT Compliances: > lookupMaxConcurrentRequests -- remove > lookupPurgeTime -- remove > lookupCtlRowStatus -- SYNTAX RowStatus (notReady(2) > WRITE-SYNTAX RowStatus (active(1), notInService(3) > > > Best Regards > > Eduardo > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Monday, March 01, 2004 6:44 PM > To: disman@ietf.org > Subject: RE: [Disman] WG last call on=20 > draft-ietf-disman-remops-mib-v2-01.txt > > > > Hi - > >> From: Eduardo Cardona >> Sent: Mar 2, 2004 9:25 AM >> To: Randy Presuhn , disman@ietf.org >> Subject: RE: [Disman] WG last call on=20 >> draft-ietf-disman-remops-mib-v2-01.txt > ... >> One simple note, I tough last call was March 5th > > No, it was supposed to end March 2. However, I'm not > going to hand it to our AD until I can be reasonably sure that it has=20 > received adequate review. > >> We at Cablelabs are interested in adding a simplified compliance=20 >> statement for ad-hoc procedure call instead of a user entry schecule=20 >> entry, so an user can do a one time execution e.g PING > > It would have been nice to have learned of this earlier, rather than=20 > during WG last call. > >> The draft we had is almost complete, >> Would be that an opportunity to add that? I can post that tomorrow in >> the list if compeling > ... > > I'd like to have this discussion sooner rather than later, so please=20 > make your specific proposal as quickly as you can. My opinion as a=20 > technical contributor is that the case for these changes would need to > be fairly compelling if they would result in the remote operations MIB > cycling at proposed rather than advancing to draft standard. As=20 > working group chair, I want to ensure that whatever course we take=20 > reflects WG consensus. So, balancing the need for bringing this to a=20 > conclusion with > the need to ensure that the technical issues are properly considered, > I'll entertain discussion of this issue ("ad hoc procedure call") until > Friday noon (Korean Time). Shortly thereafter I'll make a call on > whether there is consensus to modify the draft regarding this specific > proposal. > > Randy > > > From disman-admin@ietf.org Thu Apr 29 17:49:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04566 for ; Thu, 29 Apr 2004 17:49:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJEp-00052v-TM; Thu, 29 Apr 2004 17:38:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJ4E-0000QV-Rr for disman@optimus.ietf.org; Thu, 29 Apr 2004 17:27:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03745 for ; Thu, 29 Apr 2004 17:27:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJJ47-0000Sy-4G for disman@ietf.org; Thu, 29 Apr 2004 17:27:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJJ3D-0000Pv-00 for disman@ietf.org; Thu, 29 Apr 2004 17:26:37 -0400 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1BJJ2W-0000MJ-00; Thu, 29 Apr 2004 17:25:52 -0400 Received: from h-68-164-86-185.snvacaid.dynamic.covad.net ([68.164.86.185] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BJJ2Y-000093-00; Thu, 29 Apr 2004 14:25:54 -0700 Message-ID: <000601c42e31$1d229f60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: References: <2147483647.1082974262@[10.1.1.171]> Subject: Re: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 29 Apr 2004 14:29:54 -0700 Hi - Are there any objections to proceding as Juergen and Eduardo suggest? I'd like to see comment (pro or contra) on the specific questions Juergen raised below. Randy, disman WG chair > From: "Juergen Quittek" > To: "Eduardo Cardona" ; "Randy Presuhn" ; > Cc: "Ipcdn List (E-mail)" > Sent: Monday, April 26, 2004 1:11 AM > Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt > > Eduardo, > > Thank you for raising this issue and my apologies for this > very late reply. > > I ran into similar problems several times where a well designed > technology was too mighty or too general for being implemented > at small devices. > > Your suggestions aim at introducing additional MODULE-COMPLIANCE > clauses to the PING-MIB, the TRACEROUTE-MIB and LOOKUP-MIB modules > for allowing simpler implementations with smaller footprints. > > I support your proposal, but have a few comments, see below. > I am willing to make suggestions for minimalCompliance clauses > for the MIB modules, but first the WG should agree on two issues: > > - Is it agreed to add such clauses, that definitely require > less funtionality to be implemented? > > - what is the preferred procedure for columnar objects that > are not required for minimal compliancy? We can either > allow them to be missing completely. But this would result > in non-consecutive numbering of the remaining objects in > the minimal tables. Or we require them to be implemented > as read-only indicating that the feature that they would > serve in full compliancy is not supported. > > Please find further comments inline. > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > --On 02.03.2004 10:04 h -0700 Eduardo Cardona wrote: > > Randy, > > > > Few comments, > > > > I review the MIB and appears compelling respect to previous RFC > > > > Just one comment > > > > > > (*) traceRouteCtlMiscOptions > > It appears to me an uncanny object and rather implementations may opt to > > extend the capabilities in the private branch, could leave with that to > > avoid deprecation, of if there are field implementations. > > Currently, the MODULE-COMPLIANCE clause traceRouteCompliance requests > implementation of this object, but it may be implemented as read-only > and returning always a value of zero, if there is not further semantics > defined for it. Do you suggest to completely remove the object or to > state in the MODULE-COMPLIANCE clause that it does not need to be > implemented? > > > Regardless of the additions to the MIB I apologize for the late notice, > > > > Before sending a complete proposal and get your concept of the best > > approach, below is the proposal to add a simplified Compliance > > statement for devices not requiring to keep constant status of > > PING/TRACEROUTE operations, only remote operation per operator request. > > > > > > We are looking at your comments about the clear overlap in > > draft-ietf-disman-remops-mib-v2-01.txt > > With IPCDN draft > > http://www.ipcdn.org/drafts/draft-ietf-ipcdn-cable-gateway-tools-mib-00. > > txt ( currently out of date in IETF drafts site) which is clearly a > > subset of the DISMAN-PING-MIB > > Lectors refer to > > http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg00818. > > html > > > > Should the proposal below being include in the remops MIB or should we > > update IPCDN cable gateway Tools MIB module to be just the compliance > > statement outlined below? > > I doubt that it is a good idea to replicate large portions of the PING-MIB > in the IPCDN cable gateway Tools MIB module, as it is done right now. > > > RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null named > > log" default entry for devices not supporting the named log > > Named log is analog to disman remops draft for "OwnerIndex" and > > "TestName" where default entries are created > > (null owner, null TestName) for a manager requested operation of PING/ > > TRACEROUTE, NSLOOKUP, mostly for small foot-print devices with no > > network monitoring role at the connectivity level as pretended with this > > updated RFC. > > I don't think the remops MIB modules forbid null-named entries in the > respective tables. But currently the support of a read-write > pingCtlRowStatus is mandatory. > > Is your concrete suggestion to add something like > > OBJECT XXRowStatus > MIN-ACCESS read-only > DESCRIPTION > "Implementations may disallow the creation of named entries." > > with XX=pingCtl,traceRouteCtl,lookupCtl? > > > In summary A new Compliance Statement for small devices with no > > monitoring capabilities to : > > 1) remove the constant pulling and login information > > 2) remove the test row creation > > - CTL* Results* tables only default entries (null owner, null > > TestName) > > 3) History* tables not required. > > - New basicGroups to exclude History* objects and other objects > > which are not relevant to the simplified > > system. > > - Create an additional set of Compliance statements to require the > > new Groups and other objects Compliance > > requirements MIN-ACCESS clauses mainly > > > > Schema of the content of the new Compliance statement: > > > > List of objects not to include in basicPingGroup OBJECT-GROUP clause > > qnd/or hints for OBJECT Compliances: > > pingMaxConcurrentRequests -- remove > > Could also be read-only returning 1. > > > pingCtlDataFill -- remove or MIN-ACCESS read-only default > > value is OK > > pingCtlFrequency -- remove Only one test > > Could also be read-only returning 0. > > > pingCtlType -- remove or MIN-ACCESS read-only > > pingCtlByPassRouteTable -- remove or MIN-ACCESS read-only > > pingCtlDSField -- MIN-ACCESS read-only > > pingCtlStorageType -- remove > > pingCtlRowStatus -- SYNTAX RowStatus (notReady(2) > > WRITE-SYNTAX RowStatus (active(1), notInService(3) > > Why don't you consider removing this object? > > > pingCtlIfIndex -- not to include > > pingProbeHistory* -- not to include. > > > > List of objects not to include in basicTraceRouteGroup OBJECT-GROUP > > clause and/or hints for OBJECT Compliances: > > traceRouteMaxConcurrentRequests -- remove > > traceRouteCtlType -- remove or MIN-ACCESS read-only > > traceRouteCtlDSField -- MIN-ACCESS read-only > > traceRouteCtlByPassRouteTable -- remove or MIN-ACCESS read-only > > traceRouteCtlIfIndex -- not to include > > traceRouteCtlMiscOptions -- not to include > > traceRouteCtlDontFragment -- remove or MIN-ACCESS read-only > > traceRouteCtlInitialTtl -- remove or MIN-ACCESS > > traceRouteCtlFrequency -- remove only one test > > traceRouteCtlDescr -- remove > > traceRouteCtlCreateHopsEntries -- remove HopsEntries not required. > > traceRouteCtlRowStatus -- SYNTAX RowStatus (notReady(2) > > WRITE-SYNTAX RowStatus (active(1), notInService(3) > > traceRouteCtlStorageType -- remove > > traceRouteProbeHistory* -- not to include. > > > > List of objects not to include in basicLookupGroup OBJECT-GROUP clause > > and/or hints for OBJECT Compliances: > > lookupMaxConcurrentRequests -- remove > > lookupPurgeTime -- remove > > lookupCtlRowStatus -- SYNTAX RowStatus (notReady(2) > > WRITE-SYNTAX RowStatus (active(1), notInService(3) > > > > > > Best Regards > > > > Eduardo > > > > -----Original Message----- > > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > > Sent: Monday, March 01, 2004 6:44 PM > > To: disman@ietf.org > > Subject: RE: [Disman] WG last call on > > draft-ietf-disman-remops-mib-v2-01.txt > > > > > > > > Hi - > > > >> From: Eduardo Cardona > >> Sent: Mar 2, 2004 9:25 AM > >> To: Randy Presuhn , disman@ietf.org > >> Subject: RE: [Disman] WG last call on > >> draft-ietf-disman-remops-mib-v2-01.txt > > ... > >> One simple note, I tough last call was March 5th > > > > No, it was supposed to end March 2. However, I'm not > > going to hand it to our AD until I can be reasonably sure > > that it has received adequate review. > > > >> We at Cablelabs are interested in adding a simplified compliance > >> statement for ad-hoc procedure call instead of a user entry schecule > >> entry, so an user can do a one time execution e.g PING > > > > It would have been nice to have learned of this earlier, rather than > > during WG last call. > > > >> The draft we had is almost complete, > >> Would be that an opportunity to add that? I can post that tomorrow in > >> the list if compeling > > ... > > > > I'd like to have this discussion sooner rather than later, so please > > make > > your specific proposal as quickly as you can. My opinion as a technical > > contributor is that the case for these changes would need to be fairly > > compelling if they would result in the remote operations MIB cycling > > at proposed rather than advancing to draft standard. As working group > > chair, I want to ensure that whatever course we take reflects WG > > consensus. So, balancing the need for bringing this to a conclusion > > with > > the need to ensure that the technical issues are properly considered, > > I'll entertain discussion of this issue ("ad hoc procedure call") until > > Friday noon (Korean Time). Shortly thereafter I'll make a call on > > whether there is consensus to modify the draft regarding this specific > > proposal. > > > > Randy > > > > > > > > > > > > > > > From disman-admin@ietf.org Thu Apr 29 17:54:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04690 for ; Thu, 29 Apr 2004 17:54:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJOv-0007bH-6A; Thu, 29 Apr 2004 17:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJEl-00051i-4I for disman@optimus.ietf.org; Thu, 29 Apr 2004 17:38:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04283 for ; Thu, 29 Apr 2004 17:38:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJJEd-0000yh-FJ for disman@ietf.org; Thu, 29 Apr 2004 17:38:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJJDm-0000wJ-00 for disman@ietf.org; Thu, 29 Apr 2004 17:37:30 -0400 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1BJJCp-0000tq-00; Thu, 29 Apr 2004 17:36:31 -0400 Received: from h-68-164-86-185.snvacaid.dynamic.covad.net ([68.164.86.185] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BJJCt-0002VD-00; Thu, 29 Apr 2004 14:36:35 -0700 Message-ID: <000b01c42e32$9ad4db20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: "Ipcdn List \(E-mail\)" References: <5259D0D7419C6149B347837A2E64F46F03E264@srvxchg.cablelabs.com> Subject: Re: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 29 Apr 2004 14:40:35 -0700 Hi - As a technical contributor... > From: "Eduardo Cardona" > To: "Juergen Quittek" ; "Randy Presuhn" ; > Cc: "Ipcdn List (E-mail)" > Sent: Monday, April 26, 2004 7:16 AM > Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt ... > - Is it agreed to add such clauses, that definitely require > less funtionality to be implemented? > > - what is the preferred procedure for columnar objects that > are not required for minimal compliancy? We can either > allow them to be missing completely. But this would result > in non-consecutive numbering of the remaining objects in > the minimal tables. Or we require them to be implemented > as read-only indicating that the feature that they would > serve in full compliancy is not supported. > > > I understand the desire of having normalized process and applications > that may tune themselves by just reading static values (read-write with > read-only compliances) as a subset of the full module compliance > > It is also understood that some vendors later may complain of 'static' > requirements as a waist of resources in terms of memory and code. Just > my note in the disjunctive of the implementer vs the manager > approaches. Since a management application needs to be prepared for missing rows, missing columns, and "holes" in tables ANYWAY (due to access control), I think there would be value of read-only compliance is limited except in the case where there would actually be useful information to read. > I always though the AGENT-CAPABILLITIES is the best tool for minimize > devices implementations plus adding a robust layer in the manager side > to create the vendor, compliance/specific "what if cases", but not very > used I guess by current tools. AGENT-CAPABILITIES isn't useful for stating conformance requirements; it's just a way of saying what a particular implementation can do. > We Will be ok with the disman group decision in this matter, > > ... Ok, but we do appreciate ipcdn's input. We need to be sure the end result meets their needs. Randy From exim@www1.ietf.org Thu Apr 29 18:07:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05405 for ; Thu, 29 Apr 2004 18:07:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJW0-0000kQ-AJ for disman-archive@odin.ietf.org; Thu, 29 Apr 2004 17:56:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TLuKOR002875 for disman-archive@odin.ietf.org; Thu, 29 Apr 2004 17:56:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJQK-0007rm-W8 for disman-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 17:50:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04636 for ; Thu, 29 Apr 2004 17:50:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJJQD-0001Pg-9r for disman-web-archive@ietf.org; Thu, 29 Apr 2004 17:50:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJJPN-0001O1-00 for disman-web-archive@ietf.org; Thu, 29 Apr 2004 17:49:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJJOk-0001Lg-00 for disman-web-archive@ietf.org; Thu, 29 Apr 2004 17:48:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJEp-00052v-TM; Thu, 29 Apr 2004 17:38:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJ4E-0000QV-Rr for disman@optimus.ietf.org; Thu, 29 Apr 2004 17:27:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03745 for ; Thu, 29 Apr 2004 17:27:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJJ47-0000Sy-4G for disman@ietf.org; Thu, 29 Apr 2004 17:27:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJJ3D-0000Pv-00 for disman@ietf.org; Thu, 29 Apr 2004 17:26:37 -0400 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1BJJ2W-0000MJ-00; Thu, 29 Apr 2004 17:25:52 -0400 Received: from h-68-164-86-185.snvacaid.dynamic.covad.net ([68.164.86.185] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BJJ2Y-000093-00; Thu, 29 Apr 2004 14:25:54 -0700 Message-ID: <000601c42e31$1d229f60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: References: <2147483647.1082974262@[10.1.1.171]> Subject: Re: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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, 29 Apr 2004 14:29:54 -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.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - Are there any objections to proceding as Juergen and Eduardo suggest? I'd like to see comment (pro or contra) on the specific questions Juergen raised below. Randy, disman WG chair > From: "Juergen Quittek" > To: "Eduardo Cardona" ; "Randy Presuhn" ; > Cc: "Ipcdn List (E-mail)" > Sent: Monday, April 26, 2004 1:11 AM > Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt > > Eduardo, > > Thank you for raising this issue and my apologies for this > very late reply. > > I ran into similar problems several times where a well designed > technology was too mighty or too general for being implemented > at small devices. > > Your suggestions aim at introducing additional MODULE-COMPLIANCE > clauses to the PING-MIB, the TRACEROUTE-MIB and LOOKUP-MIB modules > for allowing simpler implementations with smaller footprints. > > I support your proposal, but have a few comments, see below. > I am willing to make suggestions for minimalCompliance clauses > for the MIB modules, but first the WG should agree on two issues: > > - Is it agreed to add such clauses, that definitely require > less funtionality to be implemented? > > - what is the preferred procedure for columnar objects that > are not required for minimal compliancy? We can either > allow them to be missing completely. But this would result > in non-consecutive numbering of the remaining objects in > the minimal tables. Or we require them to be implemented > as read-only indicating that the feature that they would > serve in full compliancy is not supported. > > Please find further comments inline. > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > --On 02.03.2004 10:04 h -0700 Eduardo Cardona wrote: > > Randy, > > > > Few comments, > > > > I review the MIB and appears compelling respect to previous RFC > > > > Just one comment > > > > > > (*) traceRouteCtlMiscOptions > > It appears to me an uncanny object and rather implementations may opt to > > extend the capabilities in the private branch, could leave with that to > > avoid deprecation, of if there are field implementations. > > Currently, the MODULE-COMPLIANCE clause traceRouteCompliance requests > implementation of this object, but it may be implemented as read-only > and returning always a value of zero, if there is not further semantics > defined for it. Do you suggest to completely remove the object or to > state in the MODULE-COMPLIANCE clause that it does not need to be > implemented? > > > Regardless of the additions to the MIB I apologize for the late notice, > > > > Before sending a complete proposal and get your concept of the best > > approach, below is the proposal to add a simplified Compliance > > statement for devices not requiring to keep constant status of > > PING/TRACEROUTE operations, only remote operation per operator request. > > > > > > We are looking at your comments about the clear overlap in > > draft-ietf-disman-remops-mib-v2-01.txt > > With IPCDN draft > > http://www.ipcdn.org/drafts/draft-ietf-ipcdn-cable-gateway-tools-mib-00. > > txt ( currently out of date in IETF drafts site) which is clearly a > > subset of the DISMAN-PING-MIB > > Lectors refer to > > http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg00818. > > html > > > > Should the proposal below being include in the remops MIB or should we > > update IPCDN cable gateway Tools MIB module to be just the compliance > > statement outlined below? > > I doubt that it is a good idea to replicate large portions of the PING-MIB > in the IPCDN cable gateway Tools MIB module, as it is done right now. > > > RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null named > > log" default entry for devices not supporting the named log > > Named log is analog to disman remops draft for "OwnerIndex" and > > "TestName" where default entries are created > > (null owner, null TestName) for a manager requested operation of PING/ > > TRACEROUTE, NSLOOKUP, mostly for small foot-print devices with no > > network monitoring role at the connectivity level as pretended with this > > updated RFC. > > I don't think the remops MIB modules forbid null-named entries in the > respective tables. But currently the support of a read-write > pingCtlRowStatus is mandatory. > > Is your concrete suggestion to add something like > > OBJECT XXRowStatus > MIN-ACCESS read-only > DESCRIPTION > "Implementations may disallow the creation of named entries." > > with XX=pingCtl,traceRouteCtl,lookupCtl? > > > In summary A new Compliance Statement for small devices with no > > monitoring capabilities to : > > 1) remove the constant pulling and login information > > 2) remove the test row creation > > - CTL* Results* tables only default entries (null owner, null > > TestName) > > 3) History* tables not required. > > - New basicGroups to exclude History* objects and other objects > > which are not relevant to the simplified > > system. > > - Create an additional set of Compliance statements to require the > > new Groups and other objects Compliance > > requirements MIN-ACCESS clauses mainly > > > > Schema of the content of the new Compliance statement: > > > > List of objects not to include in basicPingGroup OBJECT-GROUP clause > > qnd/or hints for OBJECT Compliances: > > pingMaxConcurrentRequests -- remove > > Could also be read-only returning 1. > > > pingCtlDataFill -- remove or MIN-ACCESS read-only default > > value is OK > > pingCtlFrequency -- remove Only one test > > Could also be read-only returning 0. > > > pingCtlType -- remove or MIN-ACCESS read-only > > pingCtlByPassRouteTable -- remove or MIN-ACCESS read-only > > pingCtlDSField -- MIN-ACCESS read-only > > pingCtlStorageType -- remove > > pingCtlRowStatus -- SYNTAX RowStatus (notReady(2) > > WRITE-SYNTAX RowStatus (active(1), notInService(3) > > Why don't you consider removing this object? > > > pingCtlIfIndex -- not to include > > pingProbeHistory* -- not to include. > > > > List of objects not to include in basicTraceRouteGroup OBJECT-GROUP > > clause and/or hints for OBJECT Compliances: > > traceRouteMaxConcurrentRequests -- remove > > traceRouteCtlType -- remove or MIN-ACCESS read-only > > traceRouteCtlDSField -- MIN-ACCESS read-only > > traceRouteCtlByPassRouteTable -- remove or MIN-ACCESS read-only > > traceRouteCtlIfIndex -- not to include > > traceRouteCtlMiscOptions -- not to include > > traceRouteCtlDontFragment -- remove or MIN-ACCESS read-only > > traceRouteCtlInitialTtl -- remove or MIN-ACCESS > > traceRouteCtlFrequency -- remove only one test > > traceRouteCtlDescr -- remove > > traceRouteCtlCreateHopsEntries -- remove HopsEntries not required. > > traceRouteCtlRowStatus -- SYNTAX RowStatus (notReady(2) > > WRITE-SYNTAX RowStatus (active(1), notInService(3) > > traceRouteCtlStorageType -- remove > > traceRouteProbeHistory* -- not to include. > > > > List of objects not to include in basicLookupGroup OBJECT-GROUP clause > > and/or hints for OBJECT Compliances: > > lookupMaxConcurrentRequests -- remove > > lookupPurgeTime -- remove > > lookupCtlRowStatus -- SYNTAX RowStatus (notReady(2) > > WRITE-SYNTAX RowStatus (active(1), notInService(3) > > > > > > Best Regards > > > > Eduardo > > > > -----Original Message----- > > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > > Sent: Monday, March 01, 2004 6:44 PM > > To: disman@ietf.org > > Subject: RE: [Disman] WG last call on > > draft-ietf-disman-remops-mib-v2-01.txt > > > > > > > > Hi - > > > >> From: Eduardo Cardona > >> Sent: Mar 2, 2004 9:25 AM > >> To: Randy Presuhn , disman@ietf.org > >> Subject: RE: [Disman] WG last call on > >> draft-ietf-disman-remops-mib-v2-01.txt > > ... > >> One simple note, I tough last call was March 5th > > > > No, it was supposed to end March 2. However, I'm not > > going to hand it to our AD until I can be reasonably sure > > that it has received adequate review. > > > >> We at Cablelabs are interested in adding a simplified compliance > >> statement for ad-hoc procedure call instead of a user entry schecule > >> entry, so an user can do a one time execution e.g PING > > > > It would have been nice to have learned of this earlier, rather than > > during WG last call. > > > >> The draft we had is almost complete, > >> Would be that an opportunity to add that? I can post that tomorrow in > >> the list if compeling > > ... > > > > I'd like to have this discussion sooner rather than later, so please > > make > > your specific proposal as quickly as you can. My opinion as a technical > > contributor is that the case for these changes would need to be fairly > > compelling if they would result in the remote operations MIB cycling > > at proposed rather than advancing to draft standard. As working group > > chair, I want to ensure that whatever course we take reflects WG > > consensus. So, balancing the need for bringing this to a conclusion > > with > > the need to ensure that the technical issues are properly considered, > > I'll entertain discussion of this issue ("ad hoc procedure call") until > > Friday noon (Korean Time). Shortly thereafter I'll make a call on > > whether there is consensus to modify the draft regarding this specific > > proposal. > > > > Randy > > > > > > > > > > > > > > > From exim@www1.ietf.org Thu Apr 29 18:15:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06854 for ; Thu, 29 Apr 2004 18:15:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJl4-0000Ug-3E for disman-archive@odin.ietf.org; Thu, 29 Apr 2004 18:11:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TMBsB5001893 for disman-archive@odin.ietf.org; Thu, 29 Apr 2004 18:11:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJj5-0007HY-Bg for disman-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 18:09:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05801 for ; Thu, 29 Apr 2004 18:09:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJJix-0002XB-DK for disman-web-archive@ietf.org; Thu, 29 Apr 2004 18:09:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJJhG-0002DK-00 for disman-web-archive@ietf.org; Thu, 29 Apr 2004 18:07:59 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJJgQ-00026M-00 for disman-web-archive@ietf.org; Thu, 29 Apr 2004 18:07:06 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJJTg-0002Bn-3l for disman-web-archive@ietf.org; Thu, 29 Apr 2004 17:53:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJOv-0007bH-6A; Thu, 29 Apr 2004 17:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJEl-00051i-4I for disman@optimus.ietf.org; Thu, 29 Apr 2004 17:38:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04283 for ; Thu, 29 Apr 2004 17:38:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJJEd-0000yh-FJ for disman@ietf.org; Thu, 29 Apr 2004 17:38:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJJDm-0000wJ-00 for disman@ietf.org; Thu, 29 Apr 2004 17:37:30 -0400 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1BJJCp-0000tq-00; Thu, 29 Apr 2004 17:36:31 -0400 Received: from h-68-164-86-185.snvacaid.dynamic.covad.net ([68.164.86.185] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BJJCt-0002VD-00; Thu, 29 Apr 2004 14:36:35 -0700 Message-ID: <000b01c42e32$9ad4db20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: "Ipcdn List \(E-mail\)" References: <5259D0D7419C6149B347837A2E64F46F03E264@srvxchg.cablelabs.com> Subject: Re: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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, 29 Apr 2004 14:40:35 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - As a technical contributor... > From: "Eduardo Cardona" > To: "Juergen Quittek" ; "Randy Presuhn" ; > Cc: "Ipcdn List (E-mail)" > Sent: Monday, April 26, 2004 7:16 AM > Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt ... > - Is it agreed to add such clauses, that definitely require > less funtionality to be implemented? > > - what is the preferred procedure for columnar objects that > are not required for minimal compliancy? We can either > allow them to be missing completely. But this would result > in non-consecutive numbering of the remaining objects in > the minimal tables. Or we require them to be implemented > as read-only indicating that the feature that they would > serve in full compliancy is not supported. > > > I understand the desire of having normalized process and applications > that may tune themselves by just reading static values (read-write with > read-only compliances) as a subset of the full module compliance > > It is also understood that some vendors later may complain of 'static' > requirements as a waist of resources in terms of memory and code. Just > my note in the disjunctive of the implementer vs the manager > approaches. Since a management application needs to be prepared for missing rows, missing columns, and "holes" in tables ANYWAY (due to access control), I think there would be value of read-only compliance is limited except in the case where there would actually be useful information to read. > I always though the AGENT-CAPABILLITIES is the best tool for minimize > devices implementations plus adding a robust layer in the manager side > to create the vendor, compliance/specific "what if cases", but not very > used I guess by current tools. AGENT-CAPABILITIES isn't useful for stating conformance requirements; it's just a way of saying what a particular implementation can do. > We Will be ok with the disman group decision in this matter, > > ... Ok, but we do appreciate ipcdn's input. We need to be sure the end result meets their needs. Randy From disman-admin@ietf.org Thu Apr 29 18:37:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08183 for ; Thu, 29 Apr 2004 18:37:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJK1j-0006IY-6a; Thu, 29 Apr 2004 18:29:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJK0B-0005mP-8D for disman@optimus.ietf.org; Thu, 29 Apr 2004 18:27:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07641 for ; Thu, 29 Apr 2004 18:27:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJK03-0003y3-64 for disman@ietf.org; Thu, 29 Apr 2004 18:27:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJJz5-0003uB-00 for disman@ietf.org; Thu, 29 Apr 2004 18:26:23 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BJJy6-0003nx-00; Thu, 29 Apr 2004 18:25:22 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i3TMOrGe023736; Thu, 29 Apr 2004 16:24:53 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Message-ID: <5259D0D7419C6149B347837A2E64F46F03E29A@srvxchg.cablelabs.com> Thread-Topic: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Thread-Index: AcQuNH2J7hU6Mj2lSvqCkVD7gCDb1AAAoPfQ From: "Eduardo Cardona" To: "Randy Presuhn" , Cc: "Ipcdn List (E-mail)" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 16:24:53 -0600 Content-Transfer-Encoding: quoted-printable A comment, =20 Eduardo > We Will be ok with the disman group decision in this matter, > > ... Ok, but we do appreciate ipcdn's input. We need to be sure the end result meets their needs. In my opinion Holes would be better, It minimizes objects maintenance from the vender POV plus applications are developed (sub-setted) around the minimal compliance. Although some read-only can be benefitial. pingCtlType, pingCtlByPassRouteTable read-only indicates characteristics of how function is implemented pingMaxConcurrentRequests, pingCtlDataFill can be removed --implicit or not required minimal compliance Others in IPCDN group may have a different perception. Comments? From exim@www1.ietf.org Thu Apr 29 18:53:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08839 for ; Thu, 29 Apr 2004 18:53:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKHW-0001PN-4M for disman-archive@odin.ietf.org; Thu, 29 Apr 2004 18:45:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TMjQNm005408 for disman-archive@odin.ietf.org; Thu, 29 Apr 2004 18:45:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKAz-0000eQ-Mr for disman-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 18:38:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08279 for ; Thu, 29 Apr 2004 18:38:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKAr-0004oP-DN for disman-web-archive@ietf.org; Thu, 29 Apr 2004 18:38:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKA0-0004ke-00 for disman-web-archive@ietf.org; Thu, 29 Apr 2004 18:37:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJK9C-0004gS-00 for disman-web-archive@ietf.org; Thu, 29 Apr 2004 18:36:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJK1j-0006IY-6a; Thu, 29 Apr 2004 18:29:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJK0B-0005mP-8D for disman@optimus.ietf.org; Thu, 29 Apr 2004 18:27:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07641 for ; Thu, 29 Apr 2004 18:27:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJK03-0003y3-64 for disman@ietf.org; Thu, 29 Apr 2004 18:27:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJJz5-0003uB-00 for disman@ietf.org; Thu, 29 Apr 2004 18:26:23 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BJJy6-0003nx-00; Thu, 29 Apr 2004 18:25:22 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i3TMOrGe023736; Thu, 29 Apr 2004 16:24:53 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Message-ID: <5259D0D7419C6149B347837A2E64F46F03E29A@srvxchg.cablelabs.com> Thread-Topic: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Thread-Index: AcQuNH2J7hU6Mj2lSvqCkVD7gCDb1AAAoPfQ From: "Eduardo Cardona" To: "Randy Presuhn" , Cc: "Ipcdn List (E-mail)" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 16:24:53 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable A comment, =20 Eduardo > We Will be ok with the disman group decision in this matter, > > ... Ok, but we do appreciate ipcdn's input. We need to be sure the end result meets their needs. In my opinion Holes would be better, It minimizes objects maintenance from the vender POV plus applications are developed (sub-setted) around the minimal compliance. Although some read-only can be benefitial. pingCtlType, pingCtlByPassRouteTable read-only indicates characteristics of how function is implemented pingMaxConcurrentRequests, pingCtlDataFill can be removed --implicit or not required minimal compliance Others in IPCDN group may have a different perception. Comments?