From disman-bounces@ietf.org Fri Dec 12 15:29:10 2008 Return-Path: X-Original-To: disman-archive@megatron.ietf.org Delivered-To: ietfarch-disman-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34A0E3A6A65; Fri, 12 Dec 2008 15:29:10 -0800 (PST) X-Original-To: disman@core3.amsl.com Delivered-To: disman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F62F3A6B40 for ; Fri, 12 Dec 2008 10:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.057 X-Spam-Level: X-Spam-Status: No, score=-1.057 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF3c3BelfAWf for ; Fri, 12 Dec 2008 10:56:39 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 8ABCD3A6B22 for ; Fri, 12 Dec 2008 10:56:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id BA715904A46; Fri, 12 Dec 2008 10:56:33 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11168-04; Fri, 12 Dec 2008 10:56:33 -0800 (PST) Received: from [155.53.44.238] (nurnberg.redback.com [155.53.44.238]) by prattle.redback.com (Postfix) with ESMTP id A22A7904A45; Fri, 12 Dec 2008 10:56:33 -0800 (PST) Message-ID: <4942B3E1.4070503@redback.com> Date: Fri, 12 Dec 2008 10:56:33 -0800 From: Michael Thatcher User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: disman@ietf.org Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Mailman-Approved-At: Fri, 12 Dec 2008 15:29:08 -0800 Subject: [Disman] some questions about rfc3877 (alarm mib) X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org 1. I don't understand the errata (http://www.rfc-editor.org/errata_search.php?rfc=3877) which says that ituPerceivedSeverity must be changed to alarmModelState. Why this change? Isn't this just a typo where ituPerceivedSeverity should be ituAlarmPerceivedSeverity?  There are multiple occurrances of ituPerceivedSeverity in 6.2 & 6.3 which seem to me should be ituAlarmPerceivedSeverity.

2. None of the examples use the index attribute alarmListName for objects which have this as an index, such as the value for ituAlarmGenericModel.  To be complete shouldn't the examples define an alarmListName (or use 0 as the index value indicating no name)?

3. It's not clear to me how one matches a clear event to an existing active alarm so it can be removed from the active table and the alarmActiveIndex value used for the clear event in the clear table.  It's (relatively) easy if the notification and resource IDs are the same for the clear and current active. When the notification ids are different between clear and raise, or if there are multiple active alarms, it seems that some other methodology is required which I don't particularly see.  Any insights would be appreciated.

miket

 From disman-bounces@ietf.org Sat Dec 13 10:01:52 2008 Return-Path: X-Original-To: disman-archive@megatron.ietf.org Delivered-To: ietfarch-disman-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B0B53A67EC; Sat, 13 Dec 2008 10:01:52 -0800 (PST) X-Original-To: disman@core3.amsl.com Delivered-To: disman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A1983A67EC for ; Sat, 13 Dec 2008 10:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKjwksBgCLW8 for ; Sat, 13 Dec 2008 10:01:50 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 4FF9E3A677D for ; Sat, 13 Dec 2008 10:01:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=JhM1sbaa63dNprCIdIk+m5ioiIzUBZJP2Ef+hmLjQAXHQJGDFvy4o5KlTElchi3E; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [69.3.26.45] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LBYoB-0005At-ID for disman@ietf.org; Sat, 13 Dec 2008 13:01:43 -0500 Message-ID: <009c01c95d4d$17fa14a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <4942B3E1.4070503@redback.com> Date: Sat, 13 Dec 2008 10:03:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4f9e899d516894f60fbdf9e7a855cd090350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.26.45 Subject: Re: [Disman] some questions about rfc3877 (alarm mib) X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - > From: "Michael Thatcher" > To: > Sent: Friday, December 12, 2008 10:56 AM > Subject: [Disman] some questions about rfc3877 (alarm mib) > > 1. I don't understand the errata (http://www.rfc-editor.org/errata_search.php?rfc=3877) > which says that ituPerceivedSeverity must be changed to alarmModelState. > Why this change? Isn't this just a typo where ituPerceivedSeverity should be > ituAlarmPerceivedSeverity? There are multiple occurrances of > ituPerceivedSeverity in 6.2 & 6.3 which seem to me should be > ituAlarmPerceivedSeverity. FWIW, I don't recall being involved in the processing of this erratum, so take what I say with a grain of salt... It looks like there are two things going on, and the report seems a bit garbled. You are correct that the occurrances of ituPerceivedSeverity should in general be replaced with ituAlarmPerceivedSeverity. However, the report's notes say However, ituAlarmPerceivedSeverity critical (3) should be mapped to alarmModelState 6 To match the mapping shown in Section 5.4: alarmModelState -> ituAlarmPerceivedSeverity 1 -> clear (1) 2 -> indeterminate (2) 3 -> warning (6) 4 -> minor (5) 5 -> major (4) 6 -> critical (3) I think the "mapped" refers to the steps through this particular alarm model's state machine, *NOT* a directive "that ituPerceivedSeverity must be changed to alarmModelState" and is consequently a request to change the *value* of alarmModelState. Someone would need to sit down with pencil and paper to construct the state machine for this example to verify. > 2. None of the examples use the index attribute alarmListName > for objects which have this as an index, such as the value for > ituAlarmGenericModel. To be complete shouldn't the examples > define an alarmListName (or use 0 as the index value indicating no name)? By "0" I assume you mean a zero-length string, since that is the "no name" convention for this object... Yes, that might have been nice, though probably not very interesting. > 3. It's not clear to me how one matches a clear event to an > existing active alarm so it can be removed from the active table > and the alarmActiveIndex value used for the clear event in > the clear table. It's (relatively) easy if the notification and > resource IDs are the same for the clear and current active. > When the notification ids are different between clear and raise, > or if there are multiple active alarms, it seems that some other > methodology is required which I don't particularly see. > Any insights would be appreciated. See example 6.1 for an example with different notification IDs. If there are multiple active alarms, whichever one(s) have matching clear patters will be cleared. Randy From disman-bounces@ietf.org Sat Dec 13 20:25:40 2008 Return-Path: X-Original-To: disman-archive@megatron.ietf.org Delivered-To: ietfarch-disman-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14D83A686A; Sat, 13 Dec 2008 20:25:40 -0800 (PST) X-Original-To: disman@core3.amsl.com Delivered-To: disman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E87AB3A686A for ; Sat, 13 Dec 2008 20:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bO3hMmPMqxyc for ; Sat, 13 Dec 2008 20:25:37 -0800 (PST) Received: from mta11.charter.net (mta11.charter.net [216.33.127.80]) by core3.amsl.com (Postfix) with ESMTP id 8CA933A67D0 for ; Sat, 13 Dec 2008 20:25:37 -0800 (PST) Received: from aarprv04.charter.net ([10.20.200.74]) by mta11.charter.net (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20081214042511.VZYR3882.mta11.charter.net@aarprv04.charter.net>; Sat, 13 Dec 2008 23:25:11 -0500 Received: from [127.0.0.1] (really [71.84.15.111]) by aarprv04.charter.net with ESMTP id <20081214042510.IYJQ25639.aarprv04.charter.net@[127.0.0.1]>; Sat, 13 Dec 2008 23:25:10 -0500 Message-ID: <49448AA1.3010102@charter.net> Date: Sat, 13 Dec 2008 20:25:05 -0800 From: Mike Thatcher User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: disman@ietf.org References: <4942B3E1.4070503@redback.com> <009c01c95d4d$17fa14a0$6801a8c0@oemcomputer> In-Reply-To: <009c01c95d4d$17fa14a0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Chzlrs: 0 Subject: Re: [Disman] some questions about rfc3877 (alarm mib) X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Randy Presuhn wrote: > Hi - > >> From: "Michael Thatcher" >> To: >> Sent: Friday, December 12, 2008 10:56 AM >> Subject: [Disman] some questions about rfc3877 (alarm mib) >> > >> 1. I don't understand the errata (http://www.rfc-editor.org/errata_search.php?rfc=3877) >> which says that ituPerceivedSeverity must be changed to alarmModelState. >> Why this change? Isn't this just a typo where ituPerceivedSeverity should be >> ituAlarmPerceivedSeverity? There are multiple occurrances of >> ituPerceivedSeverity in 6.2 & 6.3 which seem to me should be >> ituAlarmPerceivedSeverity. > > FWIW, I don't recall being involved in the processing of this erratum, so > take what I say with a grain of salt... > > It looks like there are two things going on, and the report seems a bit > garbled. You are correct that the occurrances of ituPerceivedSeverity > should in general be replaced with ituAlarmPerceivedSeverity. > > However, the report's notes say > However, ituAlarmPerceivedSeverity critical (3) > should be mapped to alarmModelState 6 > To match the mapping shown in Section 5.4: > alarmModelState -> ituAlarmPerceivedSeverity > 1 -> clear (1) > 2 -> indeterminate (2) > 3 -> warning (6) > 4 -> minor (5) > 5 -> major (4) > 6 -> critical (3) > > I think the "mapped" refers to the steps through this particular > alarm model's state machine, *NOT* a directive "that > ituPerceivedSeverity must be changed to alarmModelState" > and is consequently a request to change the *value* of alarmModelState. > Someone would need to sit down with pencil and paper to > construct the state machine for this example to verify. If I understand you correctly, what the errata is trying to say is that the value of alarmModelState in the example should be changed to 6 to correctly implement the requirements of the ituAlarmTable? > >> 2. None of the examples use the index attribute alarmListName >> for objects which have this as an index, such as the value for >> ituAlarmGenericModel. To be complete shouldn't the examples >> define an alarmListName (or use 0 as the index value indicating no name)? > > By "0" I assume you mean a zero-length string, since that is > the "no name" convention for this object... Yes, that might have > been nice, though probably not very interesting. > yes, 0 being a zero length string and a not interesting case but at least accurate :) >> 3. It's not clear to me how one matches a clear event to an >> existing active alarm so it can be removed from the active table >> and the alarmActiveIndex value used for the clear event in >> the clear table. It's (relatively) easy if the notification and >> resource IDs are the same for the clear and current active. >> When the notification ids are different between clear and raise, >> or if there are multiple active alarms, it seems that some other >> methodology is required which I don't particularly see. >> Any insights would be appreciated. > > See example 6.1 for an example with different notification IDs. > If there are multiple active alarms, whichever one(s) have matching > clear patters will be cleared. I think you misunderstand the question. I'm looking for what determines the selection from the active table. That is, given a notification which is a clear for some previously raised alarm, how does one find the row(s) in the alarmActiveTable to clear? What exactly does one match. It can't always be the notificationId since they may not be the same. It can't be the row pointer to the alarmModel table because they are different between clear and alarm raise events (although they are different only in the last subid). I'm assuming the resourceId has to be one object which matches between the clear notification and the row(s) the alarmActive table. It seems to me that there has to be other objects used as well as part of the selection. The other part of this question is that it seems that there could be multiple entries in the active table which could be selected. Do all of them get cleared (i.e. moved to clear table)? Only the one with the highest valued alarmModelState? mikeT From disman-bounces@ietf.org Sun Dec 14 17:40:27 2008 Return-Path: X-Original-To: disman-archive@megatron.ietf.org Delivered-To: ietfarch-disman-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD4E43A6951; Sun, 14 Dec 2008 17:40:27 -0800 (PST) X-Original-To: disman@core3.amsl.com Delivered-To: disman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11283A6903 for ; Sun, 14 Dec 2008 17:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[AWL=1.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCkCF4CDofPb for ; Sun, 14 Dec 2008 17:40:25 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id BB3263A6951 for ; Sun, 14 Dec 2008 17:40:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=DLGfZuEy55R7Egr+WkBo1eP6xfH3FXf8uEvSrvlhZu7PVbWJrfJyXp3b9wUzfhKz; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.34.216] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LC2RW-0003Pc-TG for disman@ietf.org; Sun, 14 Dec 2008 20:40:19 -0500 Message-ID: <002c01c95e56$56649300$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <4942B3E1.4070503@redback.com><009c01c95d4d$17fa14a0$6801a8c0@oemcomputer> <49448AA1.3010102@charter.net> Date: Sun, 14 Dec 2008 17:42:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e479e75e179a7181440350634c0fb89e25350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.34.216 Subject: Re: [Disman] some questions about rfc3877 (alarm mib) X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - > From: "Mike Thatcher" > To: > Sent: Saturday, December 13, 2008 8:25 PM > Subject: Re: [Disman] some questions about rfc3877 (alarm mib) .... > If I understand you correctly, what the errata is trying to say is that > the value of alarmModelState in the example should be changed to 6 to > correctly implement the requirements of the ituAlarmTable? I *think* that's what was intended. I'd love to hear from the document's editors. I haven't looked at this stuff in long time. ... > >> 3. It's not clear to me how one matches a clear event to an > >> existing active alarm so it can be removed from the active table > >> and the alarmActiveIndex value used for the clear event in > >> the clear table. It's (relatively) easy if the notification and > >> resource IDs are the same for the clear and current active. > >> When the notification ids are different between clear and raise, > >> or if there are multiple active alarms, it seems that some other > >> methodology is required which I don't particularly see. > >> Any insights would be appreciated. > > > > See example 6.1 for an example with different notification IDs. > > If there are multiple active alarms, whichever one(s) have matching > > clear patters will be cleared. > > I think you misunderstand the question. I'm looking for what determines > the selection from the active table. That is, given a notification > which is a clear for some previously raised alarm, how does one find the > row(s) in the alarmActiveTable to clear? What exactly does one match. > It can't always be the notificationId since they may not be the same. > It can't be the row pointer to the alarmModel table because they are > different between clear and alarm raise events (although they are > different only in the last subid). I'm assuming the resourceId has to > be one object which matches between the clear notification and the > row(s) the alarmActive table. It seems to me that there has to be other > objects used as well as part of the selection. The alarmModelIndex and extracted resource information from the clear can be matched up with alarmActiveModelPointer and alarmActiveResourceId to identify the row(s) of interest from the activeAlarmTable. > The other part of this question is that it seems that there could be > multiple entries in the active table which could be selected. Do all of > them get cleared (i.e. moved to clear table)? Only the one with the > highest valued alarmModelState? I would assume all should be cleared. We didn't go down the path of providing anything like CMIP-land's correlated notifications. Randy From disman-bounces@ietf.org Mon Dec 15 14:05:16 2008 Return-Path: X-Original-To: disman-archive@megatron.ietf.org Delivered-To: ietfarch-disman-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EC523A6A2A; Mon, 15 Dec 2008 14:05:16 -0800 (PST) X-Original-To: disman@core3.amsl.com Delivered-To: disman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 429983A6989 for ; Mon, 15 Dec 2008 14:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=0.802, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsWrD8mHSS-2 for ; Mon, 15 Dec 2008 14:05:12 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id E57AD3A63D2 for ; Mon, 15 Dec 2008 14:05:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 64DCC5799BC; Mon, 15 Dec 2008 14:05:06 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17838-06; Mon, 15 Dec 2008 14:05:06 -0800 (PST) Received: from [155.53.44.238] (nurnberg.redback.com [155.53.44.238]) by prattle.redback.com (Postfix) with ESMTP id 4AC935799BA; Mon, 15 Dec 2008 14:05:06 -0800 (PST) Message-ID: <4946D492.5070107@redback.com> Date: Mon, 15 Dec 2008 14:05:06 -0800 From: Michael Thatcher User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: disman@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Subject: [Disman] another question about alarmMib.. X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org the alarmActiveTable is indexed by alarmListName, alarmDataAndTime, alarmActiveIndex the alarmActiveVariableTable is indexed by alarmListName, alarmActiveIndex, alarmActiveVariableIndex. How come alarmDataAndTime are not an index into the alarmActiveVariableTable, since this table by definition has the varbind objects from the corresponding entry in alarmActiveTable? This also seems to imply that alarmActiveIndex is always unique regardless of alarmDataAndTime. Is this intentional? miket From disman-bounces@ietf.org Tue Dec 16 11:08:00 2008 Return-Path: X-Original-To: disman-archive@megatron.ietf.org Delivered-To: ietfarch-disman-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E76A3A6800; Tue, 16 Dec 2008 11:08:00 -0800 (PST) X-Original-To: disman@core3.amsl.com Delivered-To: disman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6BA43A6800 for ; Tue, 16 Dec 2008 11:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.759 X-Spam-Level: X-Spam-Status: No, score=-0.759 tagged_above=-999 required=5 tests=[AWL=-0.760, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4U+Aregr57W for ; Tue, 16 Dec 2008 11:07:58 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 279DB3A677D for ; Tue, 16 Dec 2008 11:07:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=q9GXOhprbc9tGXOUduAkAtZjns6pjRmUR/5Klpskid3i5zm6MyqHImvKTqd86mOJ; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.35.88] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LCfGc-0001ga-GL for disman@ietf.org; Tue, 16 Dec 2008 14:07:38 -0500 Message-ID: <004701c95fb1$c30f9c00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <4946D492.5070107@redback.com> Date: Tue, 16 Dec 2008 11:08:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e436ec9e9c061d5c3f6e29fcc2348e0769350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.35.88 Subject: Re: [Disman] another question about alarmMib.. X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - > From: "Michael Thatcher" > To: > Sent: Monday, December 15, 2008 2:05 PM > Subject: [Disman] another question about alarmMib.. > > the alarmActiveTable is indexed by alarmListName, alarmDataAndTime, > alarmActiveIndex > > the alarmActiveVariableTable is indexed by alarmListName, > alarmActiveIndex, alarmActiveVariableIndex. > > How come alarmDataAndTime are not an index into the > alarmActiveVariableTable, since this table by definition has the varbind > objects from the corresponding entry in alarmActiveTable? > > This also seems to imply that alarmActiveIndex is always unique > regardless of alarmDataAndTime. Is this intentional? Yes. This should make it clear why alarmDateAndTime is needed for the alarmActiveTable (it supports the ordering required for the most common use cases) and not for the alarmActiveVariableTable (these are meaningful only in the context of the alarm "containing" these variables, and a time stamp is not needed to provide uniqueness. Randy From disman-bounces@ietf.org Tue Dec 16 13:43:25 2008 Return-Path: X-Original-To: disman-archive@megatron.ietf.org Delivered-To: ietfarch-disman-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3053728C1AB; Tue, 16 Dec 2008 13:43:25 -0800 (PST) X-Original-To: disman@core3.amsl.com Delivered-To: disman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E40728C1AB for ; Tue, 16 Dec 2008 13:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzET70jm18In for ; Tue, 16 Dec 2008 13:43:22 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id C742B28C199 for ; Tue, 16 Dec 2008 13:43:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=YyJ93LvCFTGv+R/EKiWxzYTJzBfeMMqr5yXUFG1DZbVbTkp+gG+arcK9deUzwL9m; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.35.88] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LChhB-0004Jb-A7 for disman@ietf.org; Tue, 16 Dec 2008 16:43:13 -0500 Message-ID: <000301c95fc7$8b51e320$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <4946D492.5070107@redback.com> <004701c95fb1$c30f9c00$6801a8c0@oemcomputer> <49481B7C.1060301@redback.com> Date: Tue, 16 Dec 2008 13:44:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4aacb604e386b2e7b27fdf930a0057a45350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.35.88 Subject: Re: [Disman] another question about alarmMib.. X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - > From: "Michael Thatcher" > To: "Randy Presuhn" > Cc: > Sent: Tuesday, December 16, 2008 1:19 PM > Subject: Re: [Disman] another question about alarmMib.. ... > The description of alarmClearIndex says that "This object > has the same value as the alarmActiveIndex that this alarm > instance had when it was active". Does this mean that > clear events cannot be placed in this table which do not > have a related alarm in the alarmActiveTable? It sounds that way. > If there are multiple related entries in the alarmActiveTable, > does it matter which alarmActiveIndex value is used? I can't imagine why it would. It does, however, seem to be an argument for maintaining a 1:1 correspondence, even though I doubt that that was the intent. It would be good to hear from the folks who have actually already implemented or deployed this MIB. Randy From disman-bounces@ietf.org Tue Dec 16 21:52:04 2008 Return-Path: X-Original-To: disman-archive@megatron.ietf.org Delivered-To: ietfarch-disman-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 038D73A6AD0; Tue, 16 Dec 2008 21:52:04 -0800 (PST) X-Original-To: disman@core3.amsl.com Delivered-To: disman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA12028C174 for ; Tue, 16 Dec 2008 13:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TzUWhdDniYa for ; Tue, 16 Dec 2008 13:20:03 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 4676B28C173 for ; Tue, 16 Dec 2008 13:20:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 802EA1A9788; Tue, 16 Dec 2008 13:19:56 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01288-09; Tue, 16 Dec 2008 13:19:56 -0800 (PST) Received: from [155.53.44.238] (nurnberg.redback.com [155.53.44.238]) by prattle.redback.com (Postfix) with ESMTP id 652871A978C; Tue, 16 Dec 2008 13:19:56 -0800 (PST) Message-ID: <49481B7C.1060301@redback.com> Date: Tue, 16 Dec 2008 13:19:56 -0800 From: Michael Thatcher User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Randy Presuhn References: <4946D492.5070107@redback.com> <004701c95fb1$c30f9c00$6801a8c0@oemcomputer> In-Reply-To: <004701c95fb1$c30f9c00$6801a8c0@oemcomputer> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Mailman-Approved-At: Tue, 16 Dec 2008 21:52:02 -0800 Cc: disman@ietf.org Subject: Re: [Disman] another question about alarmMib.. X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Randy Presuhn wrote: 
Hi -

  
From: "Michael Thatcher" <thatcher@redback.com>
To: <disman@ietf.org>
Sent: Monday, December 15, 2008 2:05 PM
Subject: [Disman] another question about alarmMib..

the alarmActiveTable is indexed by alarmListName, alarmDataAndTime, 
alarmActiveIndex

the alarmActiveVariableTable is indexed by alarmListName, 
alarmActiveIndex, alarmActiveVariableIndex.

How come alarmDataAndTime are not an index into the 
alarmActiveVariableTable, since this table by definition has the varbind 
objects from the corresponding entry in alarmActiveTable?

This also seems to imply that alarmActiveIndex is always unique 
regardless of alarmDataAndTime.  Is this intentional?
    

Yes.  This should make it clear why alarmDateAndTime is needed
for the alarmActiveTable (it supports the ordering required for the
most common use cases) and not for the alarmActiveVariableTable
(these are meaningful only in the context of the alarm "containing"
these variables, and a time stamp is not needed to provide uniqueness.

The description of alarmClearIndex says that "This object has the same value as the alarmActiveIndex that this alarm instance had when it was active".  Does this mean that clear events cannot be placed in this table which do not have a related alarm in the alarmActiveTable?  If there are multiple related entries in the alarmActiveTable, does it matter which alarmActiveIndex value is used? 


mikeT

From disman-bounces@ietf.org Tue Dec 16 21:52:05 2008 Return-Path: X-Original-To: disman-archive@megatron.ietf.org Delivered-To: ietfarch-disman-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E75D828C135; Tue, 16 Dec 2008 21:52:04 -0800 (PST) X-Original-To: disman@core3.amsl.com Delivered-To: disman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FB8628C116 for ; Tue, 16 Dec 2008 14:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 523T-pmQmQac for ; Tue, 16 Dec 2008 14:53:03 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id DE1753A68E0 for ; Tue, 16 Dec 2008 14:53:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 0B7E1417200; Tue, 16 Dec 2008 14:52:57 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09246-06; Tue, 16 Dec 2008 14:52:56 -0800 (PST) Received: from [155.53.44.238] (nurnberg.redback.com [155.53.44.238]) by prattle.redback.com (Postfix) with ESMTP id D857C417201; Tue, 16 Dec 2008 14:52:56 -0800 (PST) Message-ID: <49483148.9030100@redback.com> Date: Tue, 16 Dec 2008 14:52:56 -0800 From: Michael Thatcher User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Randy Presuhn References: <4946D492.5070107@redback.com> <004701c95fb1$c30f9c00$6801a8c0@oemcomputer> <49481B7C.1060301@redback.com> <000301c95fc7$8b51e320$6801a8c0@oemcomputer> In-Reply-To: <000301c95fc7$8b51e320$6801a8c0@oemcomputer> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Mailman-Approved-At: Tue, 16 Dec 2008 21:52:02 -0800 Cc: disman@ietf.org Subject: Re: [Disman] another question about alarmMib.. X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Randy Presuhn wrote: 
Hi -

  
From: "Michael Thatcher" <thatcher@redback.com>
To: "Randy Presuhn" <randy_presuhn@mindspring.com>
Cc: <disman@ietf.org>
Sent: Tuesday, December 16, 2008 1:19 PM
Subject: Re: [Disman] another question about alarmMib..
    
...
  
The description of alarmClearIndex says that "This object
has the same value as the alarmActiveIndex that this alarm
instance had when it was active".  Does this mean that
clear events cannot be placed in this table which do not
have a related alarm in the alarmActiveTable?
    

It sounds that way.

  
If there are multiple related entries in the alarmActiveTable,
does it matter which alarmActiveIndex value is used?  
    

I can't imagine why it would.  It does, however, seem to be
an argument for maintaining a 1:1 correspondence, even
though I doubt that that was the intent.

It would be good to hear from the folks who have actually
already implemented or deployed this MIB.

I have been hoping for some insight from someone who has implemented this mib.

mikeT
From disman-bounces@ietf.org Wed Dec 17 14:13:30 2008 Return-Path: X-Original-To: disman-archive@megatron.ietf.org Delivered-To: ietfarch-disman-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04663A6B4C; Wed, 17 Dec 2008 14:13:30 -0800 (PST) X-Original-To: disman@core3.amsl.com Delivered-To: disman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFB5F3A6B4C for ; Wed, 17 Dec 2008 14:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.215 X-Spam-Level: X-Spam-Status: No, score=-1.215 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFmKdYRqRepP for ; Wed, 17 Dec 2008 14:13:29 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 1BBB13A6B45 for ; Wed, 17 Dec 2008 14:13:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=cMJuCkx8APVnT9W362hfLpOl/BkekStdPx6yZ030Vd/3LuAPLRHnSnn+EIYxK6O3; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.136.82] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LD4dp-0000xg-Do for disman@ietf.org; Wed, 17 Dec 2008 17:13:17 -0500 Message-ID: <00b601c96094$eeae5ac0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Disman" Date: Wed, 17 Dec 2008 14:15:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4ee9fd6160077fd398f69e25f00042e58350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.136.82 Subject: [Disman] Disman mailing list maintenance X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - As disman list admin, I've received a larged number of subscription disabled messages in the last day or so. Since at least some of these appear to be erroneous, I've "un-disabled" all the currently disabled subscribers on this list. That means that some people who manually turned off mail from this mailing list will start receiving messages again. I trust that the inconvenience to them will be offset by the value of re-enabling the subscriptions of the people who had been automatically dropped. If the list software drops these folks again, I'll assume the delivery problems are permanent and remove them from the list. Now, back to the discussion of the alarm MIB.... Randy From disman-bounces@ietf.org Wed Dec 17 19:52:49 2008 Return-Path: X-Original-To: disman-archive@megatron.ietf.org Delivered-To: ietfarch-disman-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 497153A6965; Wed, 17 Dec 2008 19:52:49 -0800 (PST) X-Original-To: disman@core3.amsl.com Delivered-To: disman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 806193A68B0; Wed, 17 Dec 2008 19:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwDVS5NzsoJE; Wed, 17 Dec 2008 19:52:46 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id A22CA3A6767; Wed, 17 Dec 2008 19:52:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=H3xUNopAjejXnfIOrLoznvY2fKBT7j0qFNIuomfJ1i8l2mfiDjwFg/Yrae8w6Tw1; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [69.3.26.131] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LD9wF-0001CT-7W; Wed, 17 Dec 2008 22:52:39 -0500 Message-ID: <00a501c960c4$55f5d300$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Disman" , Date: Wed, 17 Dec 2008 19:54:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4c27921dcf59a558a447dd8403010a10a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.26.131 Subject: [Disman] RFC 5378 license forms X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - RFC 5378 says: a. "Contribution": any submission to the IETF intended by the Contributor for publication as all or part of an Internet-Draft or RFC (except for RFC Editor Contributions described in Section 4 below) and any statement made within the context of an IETF activity. Such statements include oral statements in IETF sessions as well as written and electronic communications, made at any time or place, that are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o any Birds of a Feather (BOF) session, o the IESG, or any member thereof on behalf of the IESG, o the IAB, or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function (except for RFC Editor Contributions, as described in Section 4 below). Statements made outside of an IETF session, mailing list, or other function, that are clearly not intended to be input to an IETF activity, group, or function are not IETF Contributions in the context of this document. b. "Contributor": an individual submitting a Contribution. If you were by this definition a contributor to the work of the disman or agentx WGs during their lifetimes, please print, fill out, and sign the form http://trustee.ietf.org/docs/Contributor_Non-Exclusive_License_RFC5378.pdf If your employment agreements in effect at the time would have transferred your copyrights to your employer, please have them fill it out, too. When I find out where the signed forms should be sent, I'll forward that information. Randy From disman-bounces@ietf.org Wed Dec 17 20:07:15 2008 Return-Path: X-Original-To: disman-archive@megatron.ietf.org Delivered-To: ietfarch-disman-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F5C83A6B03; Wed, 17 Dec 2008 20:07:15 -0800 (PST) X-Original-To: disman@core3.amsl.com Delivered-To: disman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 303833A68AB; Wed, 17 Dec 2008 20:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.386 X-Spam-Level: X-Spam-Status: No, score=-1.386 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_00=-2.599, FAKE_REPLY_C=2.012] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNNOTnuK4j8n; Wed, 17 Dec 2008 20:07:13 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 476BC3A67DB; Wed, 17 Dec 2008 20:07:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Ouhmamxs/nhAOvQbTWURvxIMyf3kQKdxXcDPSbCY0U5n+avNnJwuA/jwxdRyOgdW; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [69.3.26.131] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LDAAD-0004BZ-Nx; Wed, 17 Dec 2008 23:07:05 -0500 Message-ID: <00bd01c960c6$5c12d920$6801a8c0@oemcomputer> From: "Randy Presuhn" To: , "Disman" , "LTRU Working Group" Date: Wed, 17 Dec 2008 20:09:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4ed438c4e80bb9ba337cc6cc5fbf5e456350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.26.131 Subject: Re: [Disman] RFC 5378 license forms X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - Signed http://trustee.ietf.org/docs/Contributor_Non-Exclusive_License_RFC5378.pdf forms should go to IETF Trust 1775 Wiehle Ave Reston, VA 201905108 c/o IETF Administrative Director Facsimile: 703.326.9881 Randy From disman-bounces@ietf.org Fri Dec 19 16:27:49 2008 Return-Path: X-Original-To: disman-archive@megatron.ietf.org Delivered-To: ietfarch-disman-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E153A6A93; Fri, 19 Dec 2008 16:27:49 -0800 (PST) X-Original-To: disman@core3.amsl.com Delivered-To: disman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9FEB3A6948; Fri, 19 Dec 2008 16:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAPEBHDzcQzr; Fri, 19 Dec 2008 16:27:47 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 2A9DC3A677E; Fri, 19 Dec 2008 16:27:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ZzzjbrRjI6qFYI4ha6obi/lF3G+AMZke16HTItO2DP6B2oEQYN4KxYr5S30xwHk+; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.188.204] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LDpgx-00005O-4T; Fri, 19 Dec 2008 19:27:39 -0500 Message-ID: <000601c9623a$0bfc9e60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" , "Disman" , Date: Fri, 19 Dec 2008 16:29:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4741c7c3c8ee7d21b705d78c7f81acc54350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.188.204 Subject: [Disman] Fw: RFC 5378 Contributor License Form X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - Forwarded from ietf@ietf.org . Randy > From: "Ray Pelletier" > To: "IETF Discussion" > Sent: Friday, December 19, 2008 10:35 AM > Subject: RFC 5378 Contributor License Form > > All > > The trustees are aware of the problems with respect to the RFC 5378 > implementation and possible consequences with respect to the license. > Pending a further analysis, and possible modification to the license, > we have taken the current license off-line. > > You may also expect a proposal for a temporary workaround to the > problems identified by the implementation of RFC 5378. That proposal > is currently reviewed by the trust and will be posted as an Internet > Draft soon. > > Ray Pelletier > IAD/Trustee From disman-bounces@ietf.org Mon Dec 22 17:36:31 2008 Return-Path: X-Original-To: disman-archive@megatron.ietf.org Delivered-To: ietfarch-disman-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9EF3A68BD; Mon, 22 Dec 2008 17:36:31 -0800 (PST) X-Original-To: disman@core3.amsl.com Delivered-To: disman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EE163A68BD for ; Mon, 22 Dec 2008 17:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrSBT6C6lhlk for ; Mon, 22 Dec 2008 17:36:29 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 77C0C3A67F4 for ; Mon, 22 Dec 2008 17:36:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=T8fYBvgSLFu8dg/+MVR+H2Tx1CQJqyrg9zxVUSU+Yv9YwN27EvLBYg+s7Drx+7My; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.206.195] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LEwC4-0006Ii-OE for disman@ietf.org; Mon, 22 Dec 2008 20:36:21 -0500 Message-ID: <000d01c9649f$288bd480$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <4946D492.5070107@redback.com> <004701c95fb1$c30f9c00$6801a8c0@oemcomputer> <49481B7C.1060301@redback.com> <000301c95fc7$8b51e320$6801a8c0@oemcomputer> <49483148.9030100@redback.com> Date: Mon, 22 Dec 2008 17:38:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4de325464a647e766ed51c215d2891512350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.206.195 Subject: Re: [Disman] another question about alarmMib.. X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - > From: "Michael Thatcher" > To: "Randy Presuhn" > Cc: > Sent: Tuesday, December 16, 2008 2:52 PM > Subject: Re: [Disman] another question about alarmMib.. ... > I have been hoping for some insight from someone who has implemented this mib. Any word yet, or is everyone busy celebrating their respective holidays? Randy From disman-bounces@ietf.org Tue Dec 23 07:00:28 2008 Return-Path: X-Original-To: disman-archive@megatron.ietf.org Delivered-To: ietfarch-disman-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4C2F28C163; Tue, 23 Dec 2008 07:00:28 -0800 (PST) X-Original-To: disman@core3.amsl.com Delivered-To: disman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B9228C159 for ; Tue, 23 Dec 2008 07:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2h7i3jqcLk4H for ; Tue, 23 Dec 2008 07:00:24 -0800 (PST) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 8D79628C163 for ; Tue, 23 Dec 2008 07:00:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,271,1228107600"; d="scan'208";a="146619235" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 23 Dec 2008 10:00:13 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 23 Dec 2008 10:00:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Dec 2008 16:00:12 +0100 Message-ID: In-Reply-To: <000301c95fc7$8b51e320$6801a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Disman] another question about alarmMib.. Thread-Index: Aclfx1W4hHPJ0c1HThiyEI02IgRscgFRAvGA References: <4946D492.5070107@redback.com><004701c95fb1$c30f9c00$6801a8c0@oemcomputer><49481B7C.1060301@redback.com> <000301c95fc7$8b51e320$6801a8c0@oemcomputer> From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , Subject: Re: [Disman] another question about alarmMib.. X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi, Thanks to Michael for catching an d reporting this. I apologize for the late response. All excuses related to a busy end of the year and a holiday season that already begun in some legislations apply.=20 There is a problem with this erratum and with the document itself. There are actually two problems.=20 1. The original erratum submitted by Andreas.Politze@keymile.com was reporting that the mapping=20 alarmModelState -> ituAlarmPerceivedSeverity 1 -> clear (1) 2 -> indeterminate (2) 3 -> warning (6) 4 -> minor (5) 5 -> major (4) 6 -> critical (3)=20 is not applied consistently in the examples.=20 This is correct, and we acknowledged this problem. The RFC Editor however inserted a different resolution in the RFC Errata that was published.=20 Right now I see such problems in the examples in 6.1 to 6.3.=20 2. In examples 6.2 and 6.3 ituPerceivedSeverity is used instead of ituAlarmPerceivedSeverity My proposal is to issue a new erratum to correct the above and to ask the RFC Editor to cancel or reject the current erratum.=20 With everybody's permission we shall do this in the first few weeks of the new year.=20 I hope this helps.=20 Happy Holidays, Dan > -----Original Message----- > From: disman-bounces@ietf.org=20 > [mailto:disman-bounces@ietf.org] On Behalf Of Randy Presuhn > Sent: Tuesday, December 16, 2008 11:45 PM > To: disman@ietf.org > Subject: Re: [Disman] another question about alarmMib.. >=20 > Hi - >=20 > > From: "Michael Thatcher" > > To: "Randy Presuhn" > > Cc: > > Sent: Tuesday, December 16, 2008 1:19 PM > > Subject: Re: [Disman] another question about alarmMib.. > ... > > The description of alarmClearIndex says that "This object=20 > has the same=20 > > value as the alarmActiveIndex that this alarm instance had=20 > when it was=20 > > active". Does this mean that clear events cannot be placed in this=20 > > table which do not have a related alarm in the alarmActiveTable? >=20 > It sounds that way. >=20 > > If there are multiple related entries in the=20 > alarmActiveTable, does it=20 > > matter which alarmActiveIndex value is used? >=20 > I can't imagine why it would. It does, however, seem to be=20 > an argument for maintaining a 1:1 correspondence, even though=20 > I doubt that that was the intent. >=20 > It would be good to hear from the folks who have actually=20 > already implemented or deployed this MIB. >=20 > Randy >=20 >=20 From disman-bounces@ietf.org Tue Dec 23 11:20:26 2008 Return-Path: X-Original-To: disman-archive@megatron.ietf.org Delivered-To: ietfarch-disman-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54F7E3A67FD; Tue, 23 Dec 2008 11:20:26 -0800 (PST) X-Original-To: disman@core3.amsl.com Delivered-To: disman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5836E3A67FD for ; Tue, 23 Dec 2008 11:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 393Wa0rt5mTc for ; Tue, 23 Dec 2008 11:20:24 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 702283A67D0 for ; Tue, 23 Dec 2008 11:20:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=T/h1nt0NEajCTRK8ZTbFulMUqMfvmPn/zOIL3XLrH6wxzFHzJFZQZAYK6lgJ88Gt; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [69.3.26.128] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LFCnf-0008Ia-0j for disman@ietf.org; Tue, 23 Dec 2008 14:20:15 -0500 Message-ID: <002501c96533$c9bcc960$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <4946D492.5070107@redback.com><004701c95fb1$c30f9c00$6801a8c0@oemcomputer><49481B7C.1060301@redback.com> <000301c95fc7$8b51e320$6801a8c0@oemcomputer> Date: Tue, 23 Dec 2008 11:22:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8886924630f8852f17374f5b27aaee32413829845de1f116b5a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.26.128 Subject: Re: [Disman] another question about alarmMib.. X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - Dan's suggestion makes sense to me. Randy ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" ; Sent: Tuesday, December 23, 2008 7:00 AM Subject: RE: [Disman] another question about alarmMib.. Hi, Thanks to Michael for catching an d reporting this. I apologize for the late response. All excuses related to a busy end of the year and a holiday season that already begun in some legislations apply. There is a problem with this erratum and with the document itself. There are actually two problems. 1. The original erratum submitted by Andreas.Politze@keymile.com was reporting that the mapping alarmModelState -> ituAlarmPerceivedSeverity 1 -> clear (1) 2 -> indeterminate (2) 3 -> warning (6) 4 -> minor (5) 5 -> major (4) 6 -> critical (3) is not applied consistently in the examples. This is correct, and we acknowledged this problem. The RFC Editor however inserted a different resolution in the RFC Errata that was published. Right now I see such problems in the examples in 6.1 to 6.3. 2. In examples 6.2 and 6.3 ituPerceivedSeverity is used instead of ituAlarmPerceivedSeverity My proposal is to issue a new erratum to correct the above and to ask the RFC Editor to cancel or reject the current erratum. With everybody's permission we shall do this in the first few weeks of the new year. I hope this helps. Happy Holidays, Dan