From disman-admin@ietf.org Sun Nov 2 05:30:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12416 for ; Sun, 2 Nov 2003 05:30: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 1AGFUg-0005Xg-NP; Sun, 02 Nov 2003 05:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGFTx-0005Wt-4F for disman@optimus.ietf.org; Sun, 02 Nov 2003 05:29:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12342 for ; Sun, 2 Nov 2003 05:29:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGFTt-0004kw-00 for disman@ietf.org; Sun, 02 Nov 2003 05:29:13 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AGFTs-0004km-00 for disman@ietf.org; Sun, 02 Nov 2003 05:29:13 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hA2ASaL18872 for ; Sun, 2 Nov 2003 05:28:36 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 2 Nov 2003 05:28:37 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34091BBB72@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Closed item from Randy's Review 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: Sun, 2 Nov 2003 05:28:36 -0500 Hi Current Score: The following items are closed: 1-10, 13, 15-23, 25, 27, 29-34, 36-38, 40-41, 45-46, 48, 50-54, 57, 60-61, 64, 67, 69-2, 70, 72-73, 74, 75-3 The following items are conditionally closed: 11, 12, 14, 17, 24, 28, 35, 42-44, 49, 56, 58, 62-63, 65-66, 71, 75-1, N+1,N+2, N+3 The following items are still be processed: 26, 39, 47, 55, 59, 65, 68, 69-1, 75-2, 75-4 Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, October 15, 2003 12:37 PM To: Disman (E-mail) Subject: RE: [Disman] Closed item from Randy's Review Hi For those keeping score at home, this is where we stand: The following items are closed: 1-10, 13, 15-23, 25, 27, 29-34, 36-38, 40-41, 45-46, 48, 50-54, 57, 61, 64, 67, 69-2, 70, 72-73, 74, 75-3 The following items are conditionally closed: 11, 12, 14, 17, 35, 42-43, 49, 62-63, 65-66, 71, N+1 The following items are still be processed: 24, 26, 28, 39, 44, 47, 55-56, 58-60, 65, 68, 69-1, 75-1. 75-2, 75-4, N+2, N+3 Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Tuesday, October 07, 2003 1:46 PM To: Disman (E-mail) Cc: Randy Presuhn Subject: RE: [Disman] Closed item from Randy's Review Hi As I said, the email was to ensure we were all on the same page. It is not in anybody's best interest for a -16 to be created and then have these issues brought up again. When can we expect a thumbs up/down on the remaining items? Any items not in this list will be handled separately. I want the remaining items conditionally closed before issuing -16. As in, if text X is replaced with text Y then this issue is closed. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 07, 2003 1:32 PM To: Disman (E-mail) Subject: Re: [Disman] Closed item from Randy's Review Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Tuesday, October 07, 2003 9:40 AM > Subject: [Disman] Closed item from Randy's Review ... > Just to ensure we are on the same page: Having received no indication > that the update -15 or the explanation for not making an update did > not satisfy the issue, the follow issues are considered closed: > > 1, 3-10, 13, 15-25, 27-32, 34, 36-41, 45-46, 48, 50-54, 56-57, 60-61, > 64, 67-69, 73, 74-1, 74-2, 74-4, 75-1 ... Not so fast. Numbers 24, 28, 39, 56, 60, 75-1, 68, and 69-1 I still need to check, so I object to considering them closed until I've had an opportunity to do so. I assume this means you agree to fix #17. I strongly RECOMMEND fixing 7, 13, 15a, and 16. Randy (as technical contributor) From exim@www1.ietf.org Sun Nov 2 05:30:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12431 for ; Sun, 2 Nov 2003 05:30:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGFUr-0005Yi-08 for disman-archive@odin.ietf.org; Sun, 02 Nov 2003 05:30:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA2AUCPp021365 for disman-archive@odin.ietf.org; Sun, 2 Nov 2003 05:30:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGFUq-0005YW-Ox for disman-web-archive@optimus.ietf.org; Sun, 02 Nov 2003 05:30:12 -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 FAA12371 for ; Sun, 2 Nov 2003 05:30:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGFUn-0004nT-00 for disman-web-archive@ietf.org; Sun, 02 Nov 2003 05:30:09 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGFUm-0004nP-00 for disman-web-archive@ietf.org; Sun, 02 Nov 2003 05:30:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGFUg-0005Xg-NP; Sun, 02 Nov 2003 05:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGFTx-0005Wt-4F for disman@optimus.ietf.org; Sun, 02 Nov 2003 05:29:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12342 for ; Sun, 2 Nov 2003 05:29:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGFTt-0004kw-00 for disman@ietf.org; Sun, 02 Nov 2003 05:29:13 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AGFTs-0004km-00 for disman@ietf.org; Sun, 02 Nov 2003 05:29:13 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hA2ASaL18872 for ; Sun, 2 Nov 2003 05:28:36 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 2 Nov 2003 05:28:37 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34091BBB72@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Closed item from Randy's Review 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: Sun, 2 Nov 2003 05:28:36 -0500 Hi Current Score: The following items are closed: 1-10, 13, 15-23, 25, 27, 29-34, 36-38, 40-41, 45-46, 48, 50-54, 57, 60-61, 64, 67, 69-2, 70, 72-73, 74, 75-3 The following items are conditionally closed: 11, 12, 14, 17, 24, 28, 35, 42-44, 49, 56, 58, 62-63, 65-66, 71, 75-1, N+1,N+2, N+3 The following items are still be processed: 26, 39, 47, 55, 59, 65, 68, 69-1, 75-2, 75-4 Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, October 15, 2003 12:37 PM To: Disman (E-mail) Subject: RE: [Disman] Closed item from Randy's Review Hi For those keeping score at home, this is where we stand: The following items are closed: 1-10, 13, 15-23, 25, 27, 29-34, 36-38, 40-41, 45-46, 48, 50-54, 57, 61, 64, 67, 69-2, 70, 72-73, 74, 75-3 The following items are conditionally closed: 11, 12, 14, 17, 35, 42-43, 49, 62-63, 65-66, 71, N+1 The following items are still be processed: 24, 26, 28, 39, 44, 47, 55-56, 58-60, 65, 68, 69-1, 75-1. 75-2, 75-4, N+2, N+3 Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Tuesday, October 07, 2003 1:46 PM To: Disman (E-mail) Cc: Randy Presuhn Subject: RE: [Disman] Closed item from Randy's Review Hi As I said, the email was to ensure we were all on the same page. It is not in anybody's best interest for a -16 to be created and then have these issues brought up again. When can we expect a thumbs up/down on the remaining items? Any items not in this list will be handled separately. I want the remaining items conditionally closed before issuing -16. As in, if text X is replaced with text Y then this issue is closed. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 07, 2003 1:32 PM To: Disman (E-mail) Subject: Re: [Disman] Closed item from Randy's Review Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Tuesday, October 07, 2003 9:40 AM > Subject: [Disman] Closed item from Randy's Review ... > Just to ensure we are on the same page: Having received no indication > that the update -15 or the explanation for not making an update did > not satisfy the issue, the follow issues are considered closed: > > 1, 3-10, 13, 15-25, 27-32, 34, 36-41, 45-46, 48, 50-54, 56-57, 60-61, > 64, 67-69, 73, 74-1, 74-2, 74-4, 75-1 ... Not so fast. Numbers 24, 28, 39, 56, 60, 75-1, 68, and 69-1 I still need to check, so I object to considering them closed until I've had an opportunity to do so. I assume this means you agree to fix #17. I strongly RECOMMEND fixing 7, 13, 15a, and 16. Randy (as technical contributor) From disman-admin@ietf.org Sun Nov 2 06:00:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12847 for ; Sun, 2 Nov 2003 06:00:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGFxj-0006c9-9S; Sun, 02 Nov 2003 06:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGFwx-0006bU-0s for disman@optimus.ietf.org; Sun, 02 Nov 2003 05:59:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12798 for ; Sun, 2 Nov 2003 05:59:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGFwt-00050R-00 for disman@ietf.org; Sun, 02 Nov 2003 05:59:11 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AGFws-00050H-00 for disman@ietf.org; Sun, 02 Nov 2003 05:59:10 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hA2AwdM07200 for ; Sun, 2 Nov 2003 05:58:39 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 2 Nov 2003 05:58:39 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34091BBB74@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] alarm comment 69-1 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: Sun, 2 Nov 2003 05:58:38 -0500 hi The following is the proposed resolution to Randy-69-1 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. Replace ituAlarmEntry OBJECT-TYPE SYNTAX ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table for each possible alarm severity. This table MUST be persistent across system reboots." INDEX { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity } ::= { ituAlarmTable 1 } With ituAlarmEntry OBJECT-TYPE SYNTAX ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table for each possible alarm severity. For each entry created/deleted in the alarmModeTable an entry in this table is created/deleted with a mapping from alarmModelState to ituAlarmPerceivedSeverity as follows: alarmModelState -> ituAlarmPerceivedSeverity 1 -> clear (1) 2 -> indeterminate (2) 3 -> warning (6) 4 -> minor (5) 5 -> major (4) 6 -> critical (3) All other values of alarmModelState MUST NOT appear in this table. This table MUST be persistent across system reboots." INDEX { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity } ::= { ituAlarmTable 1 } Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, October 22, 2003 8:55 AM To: Disman (E-mail) Subject: RE: [Disman] alarm comment 69-1 Hi The behaviour of the any additional extended MIBs will be defined in the extended MIBs. It doesn't make sense to define it here. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 22, 2003 2:56 AM To: Disman (E-mail) Subject: Re: [Disman] alarm comment 69-1 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Monday, October 20, 2003 6:17 AM > Subject: RE: [Disman] alarm comment 69-1 ... > The intention was certainly to have the rows created by the system > when the alarmModelTable rows are created. We did have a small hole in > this strategy which I've just over-engineered by suggesting we add a > rowStatus object. But, you are right, a simpler approach would be > better. > > If we define a default mapping from alarmModelState to > ituAlarmPerceivedSeverity, then rows can automatically be created on > systems capable of supporting the ITU-T extensions. > > alarmModelState = 0; ituAlarmPerceivedSeverity = 1 alarmModelState = > 1; ituAlarmPerceivedSeverity = 2 alarmModelState = 2; > ituAlarmPerceivedSeverity = 6 alarmModelState = 3; > ituAlarmPerceivedSeverity = 5 alarmModelState = 4; > ituAlarmPerceivedSeverity = 4 alarmModelState = 5; > ituAlarmPerceivedSeverity = 3 > > All other alarmModelState values will not cause the creation of rows > in the ituAlarmTable. ... I'm trying to understand the implications of this proposal if a system supports other extension models in addition to the ITU-T one. 1) what values of alarmModelState will cause auto-creation of rows in other extension model MIBs? 2) presumably all models will have an alarmModelState value of zero. How does a given extension model know whether it is the one (from potentially many MIBs) that needs to create a row mapping to alarmModelState zero? 3) what causes deletion of rows in these tables? Randy From exim@www1.ietf.org Sun Nov 2 06:00:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12862 for ; Sun, 2 Nov 2003 06:00:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGFxn-0006d7-DL for disman-archive@odin.ietf.org; Sun, 02 Nov 2003 06:00:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA2B073r025479 for disman-archive@odin.ietf.org; Sun, 2 Nov 2003 06:00:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGFxm-0006ck-Gv for disman-web-archive@optimus.ietf.org; Sun, 02 Nov 2003 06:00:06 -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 FAA12811 for ; Sun, 2 Nov 2003 05:59:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGFxi-00052F-00 for disman-web-archive@ietf.org; Sun, 02 Nov 2003 06:00:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGFxi-00052C-00 for disman-web-archive@ietf.org; Sun, 02 Nov 2003 06:00:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGFxj-0006c9-9S; Sun, 02 Nov 2003 06:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGFwx-0006bU-0s for disman@optimus.ietf.org; Sun, 02 Nov 2003 05:59:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12798 for ; Sun, 2 Nov 2003 05:59:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGFwt-00050R-00 for disman@ietf.org; Sun, 02 Nov 2003 05:59:11 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AGFws-00050H-00 for disman@ietf.org; Sun, 02 Nov 2003 05:59:10 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hA2AwdM07200 for ; Sun, 2 Nov 2003 05:58:39 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 2 Nov 2003 05:58:39 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34091BBB74@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] alarm comment 69-1 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: Sun, 2 Nov 2003 05:58:38 -0500 hi The following is the proposed resolution to Randy-69-1 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. Replace ituAlarmEntry OBJECT-TYPE SYNTAX ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table for each possible alarm severity. This table MUST be persistent across system reboots." INDEX { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity } ::= { ituAlarmTable 1 } With ituAlarmEntry OBJECT-TYPE SYNTAX ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table for each possible alarm severity. For each entry created/deleted in the alarmModeTable an entry in this table is created/deleted with a mapping from alarmModelState to ituAlarmPerceivedSeverity as follows: alarmModelState -> ituAlarmPerceivedSeverity 1 -> clear (1) 2 -> indeterminate (2) 3 -> warning (6) 4 -> minor (5) 5 -> major (4) 6 -> critical (3) All other values of alarmModelState MUST NOT appear in this table. This table MUST be persistent across system reboots." INDEX { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity } ::= { ituAlarmTable 1 } Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, October 22, 2003 8:55 AM To: Disman (E-mail) Subject: RE: [Disman] alarm comment 69-1 Hi The behaviour of the any additional extended MIBs will be defined in the extended MIBs. It doesn't make sense to define it here. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 22, 2003 2:56 AM To: Disman (E-mail) Subject: Re: [Disman] alarm comment 69-1 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Monday, October 20, 2003 6:17 AM > Subject: RE: [Disman] alarm comment 69-1 ... > The intention was certainly to have the rows created by the system > when the alarmModelTable rows are created. We did have a small hole in > this strategy which I've just over-engineered by suggesting we add a > rowStatus object. But, you are right, a simpler approach would be > better. > > If we define a default mapping from alarmModelState to > ituAlarmPerceivedSeverity, then rows can automatically be created on > systems capable of supporting the ITU-T extensions. > > alarmModelState = 0; ituAlarmPerceivedSeverity = 1 alarmModelState = > 1; ituAlarmPerceivedSeverity = 2 alarmModelState = 2; > ituAlarmPerceivedSeverity = 6 alarmModelState = 3; > ituAlarmPerceivedSeverity = 5 alarmModelState = 4; > ituAlarmPerceivedSeverity = 4 alarmModelState = 5; > ituAlarmPerceivedSeverity = 3 > > All other alarmModelState values will not cause the creation of rows > in the ituAlarmTable. ... I'm trying to understand the implications of this proposal if a system supports other extension models in addition to the ITU-T one. 1) what values of alarmModelState will cause auto-creation of rows in other extension model MIBs? 2) presumably all models will have an alarmModelState value of zero. How does a given extension model know whether it is the one (from potentially many MIBs) that needs to create a row mapping to alarmModelState zero? 3) what causes deletion of rows in these tables? Randy From disman-admin@ietf.org Sun Nov 2 06:19:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13152 for ; Sun, 2 Nov 2003 06:19:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGG5-0007fk-AK; Sun, 02 Nov 2003 06:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGFK-0007fS-Kg for disman@optimus.ietf.org; Sun, 02 Nov 2003 06:18:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13124 for ; Sun, 2 Nov 2003 06:18:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGGFG-0005Ar-00 for disman@ietf.org; Sun, 02 Nov 2003 06:18:10 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AGGFF-0005AO-00 for disman@ietf.org; Sun, 02 Nov 2003 06:18:09 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hA2BHdL19924 for ; Sun, 2 Nov 2003 06:17:39 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 2 Nov 2003 06:17:39 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34091BBB75@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] ituAlarmGenericModel is redundant? 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: Sun, 2 Nov 2003 06:17:38 -0500 Hi The following is the proposed resolution to Randy-68 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the description of ituAlarmGenericModel "This object points to the corresponding row in the alarmModelTable for this alarm severity." With "This object points to the corresponding row in the alarmModelTable for this alarm severity. This corresponding entry to alarmModelTable could also be derived by performing the reverse of the mapping from alarmModelState to ituAlarmPerceivedSeverity defined in the description of ituAlarmEntry to determine the appropriate { alarmListName, alarmModelIndex, alarmModelState } for this { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity }." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 24, 2003 6:48 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; Disman (E-mail) Subject: Re: [Disman] ituAlarmGenericModel is redundant? Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Friday, October 24, 2003 12:05 PM > Subject: RE: [Disman] ituAlarmGenericModel is redundant? .. > Well, the object may be redundant but technically it's not really a > duplicate. It's a reasonable compromise though. Documenting that > technically this information could be derived from other sources is > reasonable and may be helpful for people less familiar with SNMP. Most > of my complaints of the "efficiencies" we do in SNMP is that they are > often at the expense of the understanding of less experienced users. ... Ok, so If I understand the latest proposal for mapping between ITU and generic alarm models, then for a given instance { ituAlarmGenericModel x y z }, its value will always be { alarmModelNotificationId x y z}, where "x" is the length and value of the list name, "y" is the integer index, and "z" is the severity level. Did I get it right? If this is how it's supposed to work, we just need to explain in the description how this adds value. Randy From exim@www1.ietf.org Sun Nov 2 06:19:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13167 for ; Sun, 2 Nov 2003 06:19:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGG7-0007gX-AX for disman-archive@odin.ietf.org; Sun, 02 Nov 2003 06:19:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA2BJ32m029535 for disman-archive@odin.ietf.org; Sun, 2 Nov 2003 06:19:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGG7-0007gI-7F for disman-web-archive@optimus.ietf.org; Sun, 02 Nov 2003 06:19:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13149 for ; Sun, 2 Nov 2003 06:18:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGGG3-0005BJ-00 for disman-web-archive@ietf.org; Sun, 02 Nov 2003 06:18:59 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGGG2-0005BG-00 for disman-web-archive@ietf.org; Sun, 02 Nov 2003 06:18:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGG5-0007fk-AK; Sun, 02 Nov 2003 06:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGFK-0007fS-Kg for disman@optimus.ietf.org; Sun, 02 Nov 2003 06:18:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13124 for ; Sun, 2 Nov 2003 06:18:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGGFG-0005Ar-00 for disman@ietf.org; Sun, 02 Nov 2003 06:18:10 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AGGFF-0005AO-00 for disman@ietf.org; Sun, 02 Nov 2003 06:18:09 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hA2BHdL19924 for ; Sun, 2 Nov 2003 06:17:39 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 2 Nov 2003 06:17:39 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34091BBB75@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] ituAlarmGenericModel is redundant? 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: Sun, 2 Nov 2003 06:17:38 -0500 Hi The following is the proposed resolution to Randy-68 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the description of ituAlarmGenericModel "This object points to the corresponding row in the alarmModelTable for this alarm severity." With "This object points to the corresponding row in the alarmModelTable for this alarm severity. This corresponding entry to alarmModelTable could also be derived by performing the reverse of the mapping from alarmModelState to ituAlarmPerceivedSeverity defined in the description of ituAlarmEntry to determine the appropriate { alarmListName, alarmModelIndex, alarmModelState } for this { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity }." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 24, 2003 6:48 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; Disman (E-mail) Subject: Re: [Disman] ituAlarmGenericModel is redundant? Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Friday, October 24, 2003 12:05 PM > Subject: RE: [Disman] ituAlarmGenericModel is redundant? .. > Well, the object may be redundant but technically it's not really a > duplicate. It's a reasonable compromise though. Documenting that > technically this information could be derived from other sources is > reasonable and may be helpful for people less familiar with SNMP. Most > of my complaints of the "efficiencies" we do in SNMP is that they are > often at the expense of the understanding of less experienced users. ... Ok, so If I understand the latest proposal for mapping between ITU and generic alarm models, then for a given instance { ituAlarmGenericModel x y z }, its value will always be { alarmModelNotificationId x y z}, where "x" is the length and value of the list name, "y" is the integer index, and "z" is the severity level. Did I get it right? If this is how it's supposed to work, we just need to explain in the description how this adds value. Randy From disman-admin@ietf.org Sun Nov 2 06:27:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13306 for ; Sun, 2 Nov 2003 06:27:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGNo-0007pQ-9u; Sun, 02 Nov 2003 06:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGNg-0007pE-5H for disman@optimus.ietf.org; Sun, 02 Nov 2003 06:26:52 -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 GAA13297 for ; Sun, 2 Nov 2003 06:26:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGGNc-0005FH-00 for disman@ietf.org; Sun, 02 Nov 2003 06:26:48 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AGGNb-0005F7-00 for disman@ietf.org; Sun, 02 Nov 2003 06:26:47 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hA2BQHM08377 for ; Sun, 2 Nov 2003 06:26:17 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 2 Nov 2003 06:26:17 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34091BBB76@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Section 4.1.5 in draft-ietf-disman-alarm-mib-15.txt 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: Sun, 2 Nov 2003 06:26:17 -0500 Hi The following is the proposed resolution to Randy-39 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 4.1.5, replace: " The alarm model table can, and probably should, be initially populated by the system. The objects in alarmModelTable and ituAlarmTable have a MAX-ACCESS of read-write, which allows managers to modify the alarm models to suit their requirements." With "The alarm model table SHOULD be initially populated by the system. The objects in alarmModelTable and ituAlarmTable have a MAX-ACCESS of read-create, which allows managers to modify the alarm models to suit their requirements." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 16, 2003 12:08 PM To: Disman (E-mail) Subject: Re: [Disman] Section 4.1.5 in draft-ietf-disman-alarm-mib-15.txt Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Wednesday, October 15, 2003 9:56 AM > Subject: RE: [Disman] Section 4.1.5 in > draft-ietf-disman-alarm-mib-15.txt ... > The following is the proposed resolution to Randy-39 Assuming no > objection, this item will be considered closed conditional on the > proposed edit being done. > > In section 4.1.5, replace: > > " The alarm model table can, and probably should, be initially > populated by the system. The objects in alarmModelTable and > ituAlarmTable have a MAX-ACCESS of read-write, which allows managers > to modify the alarm models to suit their requirements." > > With > "The alarm model table SHOULD be initially > populated by the system. The objects in alarmModelTable and > ituAlarmTable have a MAX-ACCESS of read-write, which allows managers > to modify the alarm models to suit their requirements." ... A detail: the max access for the alarmModelTable's objects is read-create, not read-write. An open question (at this moment): depending on the clarification of the life-cycle of ituAlarmTable entries, we may need to change them to read-create. Randy From exim@www1.ietf.org Sun Nov 2 06:27:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13321 for ; Sun, 2 Nov 2003 06:27:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGNp-0007qD-DF for disman-archive@odin.ietf.org; Sun, 02 Nov 2003 06:27:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA2BR1nJ030135 for disman-archive@odin.ietf.org; Sun, 2 Nov 2003 06:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGNp-0007py-9o for disman-web-archive@optimus.ietf.org; Sun, 02 Nov 2003 06:27:01 -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 GAA13301 for ; Sun, 2 Nov 2003 06:26:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGGNl-0005FP-00 for disman-web-archive@ietf.org; Sun, 02 Nov 2003 06:26:57 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGGNk-0005FM-00 for disman-web-archive@ietf.org; Sun, 02 Nov 2003 06:26:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGNo-0007pQ-9u; Sun, 02 Nov 2003 06:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGNg-0007pE-5H for disman@optimus.ietf.org; Sun, 02 Nov 2003 06:26:52 -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 GAA13297 for ; Sun, 2 Nov 2003 06:26:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGGNc-0005FH-00 for disman@ietf.org; Sun, 02 Nov 2003 06:26:48 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AGGNb-0005F7-00 for disman@ietf.org; Sun, 02 Nov 2003 06:26:47 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hA2BQHM08377 for ; Sun, 2 Nov 2003 06:26:17 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 2 Nov 2003 06:26:17 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34091BBB76@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Section 4.1.5 in draft-ietf-disman-alarm-mib-15.txt 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: Sun, 2 Nov 2003 06:26:17 -0500 Hi The following is the proposed resolution to Randy-39 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 4.1.5, replace: " The alarm model table can, and probably should, be initially populated by the system. The objects in alarmModelTable and ituAlarmTable have a MAX-ACCESS of read-write, which allows managers to modify the alarm models to suit their requirements." With "The alarm model table SHOULD be initially populated by the system. The objects in alarmModelTable and ituAlarmTable have a MAX-ACCESS of read-create, which allows managers to modify the alarm models to suit their requirements." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 16, 2003 12:08 PM To: Disman (E-mail) Subject: Re: [Disman] Section 4.1.5 in draft-ietf-disman-alarm-mib-15.txt Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Wednesday, October 15, 2003 9:56 AM > Subject: RE: [Disman] Section 4.1.5 in > draft-ietf-disman-alarm-mib-15.txt ... > The following is the proposed resolution to Randy-39 Assuming no > objection, this item will be considered closed conditional on the > proposed edit being done. > > In section 4.1.5, replace: > > " The alarm model table can, and probably should, be initially > populated by the system. The objects in alarmModelTable and > ituAlarmTable have a MAX-ACCESS of read-write, which allows managers > to modify the alarm models to suit their requirements." > > With > "The alarm model table SHOULD be initially > populated by the system. The objects in alarmModelTable and > ituAlarmTable have a MAX-ACCESS of read-write, which allows managers > to modify the alarm models to suit their requirements." ... A detail: the max access for the alarmModelTable's objects is read-create, not read-write. An open question (at this moment): depending on the clarification of the life-cycle of ituAlarmTable entries, we may need to change them to read-create. Randy From disman-admin@ietf.org Sun Nov 2 06:34:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13474 for ; Sun, 2 Nov 2003 06:34:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGUb-000812-0H; Sun, 02 Nov 2003 06:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGTh-0007zI-93 for disman@optimus.ietf.org; Sun, 02 Nov 2003 06:33:05 -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 GAA13448 for ; Sun, 2 Nov 2003 06:32:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGGTc-0005JV-00 for disman@ietf.org; Sun, 02 Nov 2003 06:33:00 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AGGTb-0005JI-00 for disman@ietf.org; Sun, 02 Nov 2003 06:33:00 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hA2BWOL20085 for ; Sun, 2 Nov 2003 06:32:24 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 2 Nov 2003 06:32:24 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34091BBB77@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt 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: Sun, 2 Nov 2003 06:32:24 -0500 Hi The following is the proposed resolution to Randy-26 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 3.3.5 replace " The Alarm MIB provides a generic method for identifying the resource by extracting and building a resource ID from the Notification varbinds. Solutions interested in being able to differentiate the source of the alarm by means other than the source IP address and resource ID should create separate alarm lists such that each context/source IP address pair is its own list." With "The Alarm MIB provides a generic method for identifying the resource by extracting and building a resource ID from the Notification varbinds. It records the relevant information needed to locate the source of the alarm." Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Friday, October 17, 2003 7:53 AM To: Disman (E-mail) Subject: RE: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt Hi Oops. " The Alarm MIB provides a generic method for identifying the resource by extracting and building a resource ID from the Notification varbinds. Solutions interested in being able to specify alarms from sources in different SNMP contexts can create separate alarm lists such that each context is its own list." Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Friday, October 17, 2003 7:37 AM To: Disman (E-mail) Subject: RE: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt Hi How about " The Alarm MIB provides a generic method for identifying the resource by extracting and building a resource ID from the Notification varbinds. Solutions interested in being able to specify alarms from sources in different SNMP contexts can create separate alarm lists such that each context pair is its own list." The point of the text was really just to address the multi-context thing, so removing the IP reference makes it cleaner. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 16, 2003 5:04 PM To: Disman (E-mail) Subject: Re: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt Hi - I still don't see why the "should" language is needed. Am I being unnecessarily dense? Did I miss where the i-d explains why applications should do this? Also, context/IP is *not* enough to uniquely identify a source. Think DHCP. That's why I proposed the more general language. Randy > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Thursday, October 16, 2003 1:16 PM > Subject: RE: [Disman] Section 3.3.5 of > draft-ietf-disman-alarm-mib-15.txt > > Hi > > The following is the proposed resolution to Randy-26 Assuming no > objection, this item will be considered closed conditional on the > proposed edit being done. > > In section 3.3.5 replace > > " The Alarm MIB provides a generic method for identifying the resource > by extracting and building a resource ID from the Notification > varbinds. Solutions interested in being able to differentiate the > source of the alarm by means other than the source IP address and > resource ID should create separate alarm lists such that each > context/source IP address pair is its own list." > > With > > " The Alarm MIB provides a generic method for identifying the resource > by extracting and building a resource ID from the Notification > varbinds. Solutions interested in being able to specify alarms from > sources in different SNMP contexts should create separate alarm lists > such that each (context, source IP address) pair is its own list." > > Sharon > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Friday, October 03, 2003 1:50 AM > To: Disman (E-mail) > Subject: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt > > > Hi - > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Cc: ; "Randy Presuhn" > > ; "Romascanu, Dan (Dan)" > > > Sent: Monday, September 29, 2003 7:34 AM > > Subject: [Disman] RE: Comments on draft-ietf-disman-alarm-mib-14.txt > ... > > 26) Section 3.3.5: "Solutions interested in being able to > > differentiate > the > > source of the alarm by means other than the source IP address and > > resource ID" is at odds with what's actually done in the > > alarmActiveEntry and alarmClearEntry. Both include information > > for the LocalSnmpEngineOrZeroLenStr, AddressType, EngineAddress, > > and ContextName. > ... > > The text still doesn't match the actual operation of the MIB. The > current text says: > The Alarm MIB provides a generic method for identifying the resource > by extracting and building a resource ID from the Notification > varbinds. Solutions interested in being able to differentiate the > source of the alarm by means other than the source IP address and > resource ID should create separate alarm lists such that each > context/source IP address pair is its own list. > > I still don't see why one would need to create separate alarm lists, > nor do I see why we're talking about IP addresses when one also needs > a port (if one is even using IP!) to find an agent. > > Proposed replacement text: > The Alarm MIB provides a generic method for identifying the resource > by extracting and building a resource ID from the Notification > varbinds. It records the relevant information needed to locate the > source of the alarm. > > Randy > > > > From exim@www1.ietf.org Sun Nov 2 06:34:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13489 for ; Sun, 2 Nov 2003 06:34:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGUi-00081s-N4 for disman-archive@odin.ietf.org; Sun, 02 Nov 2003 06:34:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA2BY8Ka030858 for disman-archive@odin.ietf.org; Sun, 2 Nov 2003 06:34:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGUi-00081d-JZ for disman-web-archive@optimus.ietf.org; Sun, 02 Nov 2003 06:34:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13458 for ; Sun, 2 Nov 2003 06:33:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGGUe-0005Jm-00 for disman-web-archive@ietf.org; Sun, 02 Nov 2003 06:34:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGGUe-0005Jj-00 for disman-web-archive@ietf.org; Sun, 02 Nov 2003 06:34:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGUb-000812-0H; Sun, 02 Nov 2003 06:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGTh-0007zI-93 for disman@optimus.ietf.org; Sun, 02 Nov 2003 06:33:05 -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 GAA13448 for ; Sun, 2 Nov 2003 06:32:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGGTc-0005JV-00 for disman@ietf.org; Sun, 02 Nov 2003 06:33:00 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AGGTb-0005JI-00 for disman@ietf.org; Sun, 02 Nov 2003 06:33:00 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hA2BWOL20085 for ; Sun, 2 Nov 2003 06:32:24 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 2 Nov 2003 06:32:24 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34091BBB77@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt 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: Sun, 2 Nov 2003 06:32:24 -0500 Hi The following is the proposed resolution to Randy-26 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 3.3.5 replace " The Alarm MIB provides a generic method for identifying the resource by extracting and building a resource ID from the Notification varbinds. Solutions interested in being able to differentiate the source of the alarm by means other than the source IP address and resource ID should create separate alarm lists such that each context/source IP address pair is its own list." With "The Alarm MIB provides a generic method for identifying the resource by extracting and building a resource ID from the Notification varbinds. It records the relevant information needed to locate the source of the alarm." Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Friday, October 17, 2003 7:53 AM To: Disman (E-mail) Subject: RE: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt Hi Oops. " The Alarm MIB provides a generic method for identifying the resource by extracting and building a resource ID from the Notification varbinds. Solutions interested in being able to specify alarms from sources in different SNMP contexts can create separate alarm lists such that each context is its own list." Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Friday, October 17, 2003 7:37 AM To: Disman (E-mail) Subject: RE: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt Hi How about " The Alarm MIB provides a generic method for identifying the resource by extracting and building a resource ID from the Notification varbinds. Solutions interested in being able to specify alarms from sources in different SNMP contexts can create separate alarm lists such that each context pair is its own list." The point of the text was really just to address the multi-context thing, so removing the IP reference makes it cleaner. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 16, 2003 5:04 PM To: Disman (E-mail) Subject: Re: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt Hi - I still don't see why the "should" language is needed. Am I being unnecessarily dense? Did I miss where the i-d explains why applications should do this? Also, context/IP is *not* enough to uniquely identify a source. Think DHCP. That's why I proposed the more general language. Randy > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Thursday, October 16, 2003 1:16 PM > Subject: RE: [Disman] Section 3.3.5 of > draft-ietf-disman-alarm-mib-15.txt > > Hi > > The following is the proposed resolution to Randy-26 Assuming no > objection, this item will be considered closed conditional on the > proposed edit being done. > > In section 3.3.5 replace > > " The Alarm MIB provides a generic method for identifying the resource > by extracting and building a resource ID from the Notification > varbinds. Solutions interested in being able to differentiate the > source of the alarm by means other than the source IP address and > resource ID should create separate alarm lists such that each > context/source IP address pair is its own list." > > With > > " The Alarm MIB provides a generic method for identifying the resource > by extracting and building a resource ID from the Notification > varbinds. Solutions interested in being able to specify alarms from > sources in different SNMP contexts should create separate alarm lists > such that each (context, source IP address) pair is its own list." > > Sharon > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Friday, October 03, 2003 1:50 AM > To: Disman (E-mail) > Subject: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt > > > Hi - > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Cc: ; "Randy Presuhn" > > ; "Romascanu, Dan (Dan)" > > > Sent: Monday, September 29, 2003 7:34 AM > > Subject: [Disman] RE: Comments on draft-ietf-disman-alarm-mib-14.txt > ... > > 26) Section 3.3.5: "Solutions interested in being able to > > differentiate > the > > source of the alarm by means other than the source IP address and > > resource ID" is at odds with what's actually done in the > > alarmActiveEntry and alarmClearEntry. Both include information > > for the LocalSnmpEngineOrZeroLenStr, AddressType, EngineAddress, > > and ContextName. > ... > > The text still doesn't match the actual operation of the MIB. The > current text says: > The Alarm MIB provides a generic method for identifying the resource > by extracting and building a resource ID from the Notification > varbinds. Solutions interested in being able to differentiate the > source of the alarm by means other than the source IP address and > resource ID should create separate alarm lists such that each > context/source IP address pair is its own list. > > I still don't see why one would need to create separate alarm lists, > nor do I see why we're talking about IP addresses when one also needs > a port (if one is even using IP!) to find an agent. > > Proposed replacement text: > The Alarm MIB provides a generic method for identifying the resource > by extracting and building a resource ID from the Notification > varbinds. It records the relevant information needed to locate the > source of the alarm. > > Randy > > > > From disman-admin@ietf.org Sun Nov 2 06:37:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13563 for ; Sun, 2 Nov 2003 06:37:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGXU-0008CI-Nn; Sun, 02 Nov 2003 06:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGX8-0008Bv-3v for disman@optimus.ietf.org; Sun, 02 Nov 2003 06:36:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13552 for ; Sun, 2 Nov 2003 06:36:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGGX3-0005L8-00 for disman@ietf.org; Sun, 02 Nov 2003 06:36:33 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AGGX3-0005Kt-00 for disman@ietf.org; Sun, 02 Nov 2003 06:36:33 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hA2Ba3L20174 for ; Sun, 2 Nov 2003 06:36:03 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 2 Nov 2003 06:36:03 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34091BBB78@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-m ib-15.txt 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: Sun, 2 Nov 2003 06:36:02 -0500 Hi The following is the proposed resolution to Randy-59 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the description of alarmActiveContextName replace "The name of the SNMP MIB context from which the alarm came. For SNMPv1 alarms this is the community string from the Trap. Note that care needs to be taken when selecting community strings to ensure that these can be represented as a well-formed SnmpAdminString. If the alarm's source SNMP engine is known not to support multiple contexts, this object is a zero length string." With "The name of the SNMP MIB context from which the alarm came. For SNMPv1 alarms this is the community string from the Trap. Note that care MUST be taken when selecting community strings to ensure that these can be represented as a well-formed SnmpAdminString. Community or Context names that are not well-formed SnmpAdminStrings will be mapped to zero length strings. If the alarm's source SNMP engine is known not to support multiple contexts, this object is a zero length string." And add the following text to the security considerations section "Although the use of community strings in SNMPv1 is not considered an effective means of providing security, security administrators SHOULD consider whether the fact that alarmActiveContextName can reveal community string values would make this object sensitive in their environment." Sharon -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Wednesday, October 22, 2003 3:15 PM To: Randy Presuhn; Disman (E-mail) Subject: RE: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt OK to me as well. Dan > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: 22 October, 2003 3:12 AM > To: Disman (E-mail) > Subject: Re: [Disman] alarmActiveContextName in > draft-ietf-disman-alarm-mib-15.txt > > > Hi - > > This looks fine to me. I know that in the past there has > been concern about > MIB objects that provide access to community strings, > insecure as they are. > Perhaps we should add words to the security considerations > section explaining > the (perceived) sensitivity of this object, perhaps saying > something like > "Although the use of community strings in SNMPv1 is not > considered an effective > means of providing security, security administrators SHOULD > consider whether > the fact that alarmActiveContextName can reveal community > string values would > make this object sensitive in their environment." (I'm sure > someone can find > better words!) > > Randy > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Saturday, October 18, 2003 3:15 PM > > Subject: RE: [Disman] alarmActiveContextName in > draft-ietf-disman-alarm-mib-15.txt > > > > > Hi > > > > The following is the proposed resolution to Randy-59 > Assuming no objection, > > this item will be considered closed conditional on the > proposed edit being > > done. > > > > In the description of alarmActiveContextName replace > > > > "The name of the SNMP MIB context from which the > alarm came. > > For SNMPv1 alarms this is the community string > from the Trap. > > Note that care needs to be taken when selecting community > > strings to ensure that these can be represented as a > > well-formed SnmpAdminString. > > > > If the alarm's source SNMP engine is known not to support > > multiple contexts, this object is a zero length string." > > > > With > > > > "The name of the SNMP MIB context from which the > alarm came. > > For SNMPv1 alarms this is the community string > from the Trap. > > Note that care MUST be taken when selecting community > > strings to ensure that these can be represented as a > > well-formed SnmpAdminString. Community or Context names > > that are not well-formed SnmpAdminStrings will be mapped > > to zero length strings. > > > > If the alarm's source SNMP engine is known not to support > > multiple contexts, this object is a zero length string." > > > > -----Original Message----- > > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > > Sent: Thursday, October 02, 2003 4:12 PM > > To: Disman (E-mail) > > Subject: Re: [Disman] alarmActiveContextName in > > draft-ietf-disman-alarm-mib-15.txt > > > > > > Hi - > > > > As technical contributor... > > > > > From: "Romascanu, Dan (Dan)" > > > To: "Randy Presuhn" ; > "Disman (E-mail)" > > > > > > Sent: Thursday, October 02, 2003 10:22 AM > > > Subject: RE: [Disman] alarmActiveContextName in > > draft-ietf-disman-alarm-mib-15.txt > > > > > > ... > > > > still doesn't tell us what a system is supposed to do when its > > > > handling a trap with a community string of, say, 0xff. > > > > > > I was meaning that a NULL string is being added in this > case. Yeah, > > > it's more than just a MUST. > > > > If that's what's intended, it should say so. > > I'm not sure whether it's the best possible solution, > > but this is a corner case that's probably not worth > over-engineering. > > > > ... > > > I am not familiar enough with AgentX or SMUX, but how do they deal > > > with notifications received from sub-agents that need to > be forwarded? > > > This should not be different? Also, was not SMUX a > pre-SNMPv2 beast? > > > > Yeah, let's focus on AgentX; SMUX is a red herring here. For AgentX, > > the subagent supplies the context name as part of the notification. > > The master agent need never have > heard of it > > before, though if VACM is in use an entry with a zero-length > > vacmAccessContextPrefix and vacmAccessContextMatch equal to > prefix(2) would > > be needed to let these things get to the wire. > > > > The important thing is that the information is supplied by > the subagent, and > > the master agent doesn't know in advance how many different > contexts it > > might see in these notifications. > > > > Furthermore, RFC 2741 is (unfortunately) explicit in > section 6.1.1 in saying > > that > > > > AgentX provides a mechanism for transmitting a context > specification > > within relevant PDUs, but does not place any constraints on the > > content of that specification. > > ... > > context. The context is represented as an Octet String. > There are > > no constraints on its length or contents. > > > > I'm willing to treat non-SnmpAdminString contexts from > subagents as a > > pathological case. Lumping them in with the goofy community > strings and > > mapping them to a zero-length alarmActiveContextName. > (which would be > > indistinguishable from the default context) is probably as > good a solution > > as any. > > > > Sooo, back to the original problem: > > > > I think the first paragraph should state that community or > context values > > that violate the SYNTAX are to be mapped to a zero-length > string. I think > > the second paragraph should be MAY rather than MUST. > > > > Randy > > > > > > > > > > > > From exim@www1.ietf.org Sun Nov 2 06:37:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13578 for ; Sun, 2 Nov 2003 06:37:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGXX-0008F4-4I for disman-archive@odin.ietf.org; Sun, 02 Nov 2003 06:37:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA2Bb2Qs031668 for disman-archive@odin.ietf.org; Sun, 2 Nov 2003 06:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGXW-0008EZ-BA for disman-web-archive@optimus.ietf.org; Sun, 02 Nov 2003 06:37:02 -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 GAA13558 for ; Sun, 2 Nov 2003 06:36:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGGXS-0005LN-00 for disman-web-archive@ietf.org; Sun, 02 Nov 2003 06:36:58 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGGXR-0005LK-00 for disman-web-archive@ietf.org; Sun, 02 Nov 2003 06:36:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGXU-0008CI-Nn; Sun, 02 Nov 2003 06:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGGX8-0008Bv-3v for disman@optimus.ietf.org; Sun, 02 Nov 2003 06:36:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13552 for ; Sun, 2 Nov 2003 06:36:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGGX3-0005L8-00 for disman@ietf.org; Sun, 02 Nov 2003 06:36:33 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AGGX3-0005Kt-00 for disman@ietf.org; Sun, 02 Nov 2003 06:36:33 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hA2Ba3L20174 for ; Sun, 2 Nov 2003 06:36:03 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 2 Nov 2003 06:36:03 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34091BBB78@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-m ib-15.txt 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: Sun, 2 Nov 2003 06:36:02 -0500 Hi The following is the proposed resolution to Randy-59 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the description of alarmActiveContextName replace "The name of the SNMP MIB context from which the alarm came. For SNMPv1 alarms this is the community string from the Trap. Note that care needs to be taken when selecting community strings to ensure that these can be represented as a well-formed SnmpAdminString. If the alarm's source SNMP engine is known not to support multiple contexts, this object is a zero length string." With "The name of the SNMP MIB context from which the alarm came. For SNMPv1 alarms this is the community string from the Trap. Note that care MUST be taken when selecting community strings to ensure that these can be represented as a well-formed SnmpAdminString. Community or Context names that are not well-formed SnmpAdminStrings will be mapped to zero length strings. If the alarm's source SNMP engine is known not to support multiple contexts, this object is a zero length string." And add the following text to the security considerations section "Although the use of community strings in SNMPv1 is not considered an effective means of providing security, security administrators SHOULD consider whether the fact that alarmActiveContextName can reveal community string values would make this object sensitive in their environment." Sharon -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Wednesday, October 22, 2003 3:15 PM To: Randy Presuhn; Disman (E-mail) Subject: RE: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt OK to me as well. Dan > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: 22 October, 2003 3:12 AM > To: Disman (E-mail) > Subject: Re: [Disman] alarmActiveContextName in > draft-ietf-disman-alarm-mib-15.txt > > > Hi - > > This looks fine to me. I know that in the past there has > been concern about > MIB objects that provide access to community strings, > insecure as they are. > Perhaps we should add words to the security considerations > section explaining > the (perceived) sensitivity of this object, perhaps saying > something like > "Although the use of community strings in SNMPv1 is not > considered an effective > means of providing security, security administrators SHOULD > consider whether > the fact that alarmActiveContextName can reveal community > string values would > make this object sensitive in their environment." (I'm sure > someone can find > better words!) > > Randy > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Saturday, October 18, 2003 3:15 PM > > Subject: RE: [Disman] alarmActiveContextName in > draft-ietf-disman-alarm-mib-15.txt > > > > > Hi > > > > The following is the proposed resolution to Randy-59 > Assuming no objection, > > this item will be considered closed conditional on the > proposed edit being > > done. > > > > In the description of alarmActiveContextName replace > > > > "The name of the SNMP MIB context from which the > alarm came. > > For SNMPv1 alarms this is the community string > from the Trap. > > Note that care needs to be taken when selecting community > > strings to ensure that these can be represented as a > > well-formed SnmpAdminString. > > > > If the alarm's source SNMP engine is known not to support > > multiple contexts, this object is a zero length string." > > > > With > > > > "The name of the SNMP MIB context from which the > alarm came. > > For SNMPv1 alarms this is the community string > from the Trap. > > Note that care MUST be taken when selecting community > > strings to ensure that these can be represented as a > > well-formed SnmpAdminString. Community or Context names > > that are not well-formed SnmpAdminStrings will be mapped > > to zero length strings. > > > > If the alarm's source SNMP engine is known not to support > > multiple contexts, this object is a zero length string." > > > > -----Original Message----- > > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > > Sent: Thursday, October 02, 2003 4:12 PM > > To: Disman (E-mail) > > Subject: Re: [Disman] alarmActiveContextName in > > draft-ietf-disman-alarm-mib-15.txt > > > > > > Hi - > > > > As technical contributor... > > > > > From: "Romascanu, Dan (Dan)" > > > To: "Randy Presuhn" ; > "Disman (E-mail)" > > > > > > Sent: Thursday, October 02, 2003 10:22 AM > > > Subject: RE: [Disman] alarmActiveContextName in > > draft-ietf-disman-alarm-mib-15.txt > > > > > > ... > > > > still doesn't tell us what a system is supposed to do when its > > > > handling a trap with a community string of, say, 0xff. > > > > > > I was meaning that a NULL string is being added in this > case. Yeah, > > > it's more than just a MUST. > > > > If that's what's intended, it should say so. > > I'm not sure whether it's the best possible solution, > > but this is a corner case that's probably not worth > over-engineering. > > > > ... > > > I am not familiar enough with AgentX or SMUX, but how do they deal > > > with notifications received from sub-agents that need to > be forwarded? > > > This should not be different? Also, was not SMUX a > pre-SNMPv2 beast? > > > > Yeah, let's focus on AgentX; SMUX is a red herring here. For AgentX, > > the subagent supplies the context name as part of the notification. > > The master agent need never have > heard of it > > before, though if VACM is in use an entry with a zero-length > > vacmAccessContextPrefix and vacmAccessContextMatch equal to > prefix(2) would > > be needed to let these things get to the wire. > > > > The important thing is that the information is supplied by > the subagent, and > > the master agent doesn't know in advance how many different > contexts it > > might see in these notifications. > > > > Furthermore, RFC 2741 is (unfortunately) explicit in > section 6.1.1 in saying > > that > > > > AgentX provides a mechanism for transmitting a context > specification > > within relevant PDUs, but does not place any constraints on the > > content of that specification. > > ... > > context. The context is represented as an Octet String. > There are > > no constraints on its length or contents. > > > > I'm willing to treat non-SnmpAdminString contexts from > subagents as a > > pathological case. Lumping them in with the goofy community > strings and > > mapping them to a zero-length alarmActiveContextName. > (which would be > > indistinguishable from the default context) is probably as > good a solution > > as any. > > > > Sooo, back to the original problem: > > > > I think the first paragraph should state that community or > context values > > that violate the SYNTAX are to be mapped to a zero-length > string. I think > > the second paragraph should be MAY rather than MUST. > > > > Randy > > > > > > > > > > > > From disman-admin@ietf.org Tue Nov 4 12:20:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23696 for ; Tue, 4 Nov 2003 12:20:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4qZ-0003Tq-Bo; Tue, 04 Nov 2003 12:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4pn-0003S7-To for disman@optimus.ietf.org; Tue, 04 Nov 2003 12:19:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23591; Tue, 4 Nov 2003 12:19:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4pl-00015k-00; Tue, 04 Nov 2003 12:19:13 -0500 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AH4pl-00015f-00; Tue, 04 Nov 2003 12:19:13 -0500 Received: from h-68-165-69-162.snvacaid.dynamic.covad.net ([68.165.69.162] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AH4pj-0006NB-00; Tue, 04 Nov 2003 09:19:11 -0800 Message-ID: <001e01c3a22e$c1fd3ca0$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] changes to MIB IPR boilerplate 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, 3 Nov 2003 09:20:19 -0800 Hi - The IESG has announced a change to the copyright notice that needs to be embedded in MIB MODULE-IDENTITY sections. The change was described in the IESG announcement. The relevant portion follows: > From: "The IESG" > To: > Cc: "Internet Architecture Board" ; "RFC Editor" ; > Sent: Monday, November 03, 2003 12:27 PM > Subject: Protocol Action: 'IETF Rights in Contributions' to BCP ... > RFC EDITOR NOTE: > > In section 5.6 of draft-ietf-ipr-submission-rights, please make the > following changes: > > OLD: > > "Copyright (C) The Internet Society . The initial > version of this MIB module was published in RFC XXXX; for full > legal notices see the RFC itself or see: > http://www.ietf.org/copyrights/ianamib.html." > > NEW: > > "Copyright (C) The Internet Society . The initial > version of this MIB module was published in RFC XXXX; for full > legal notices see the RFC itself. Supplementary information > may be available on http://www.ietf.org/copyrights/ianamib.html." ... Randy From exim@www1.ietf.org Tue Nov 4 12:20:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23711 for ; Tue, 4 Nov 2003 12:20:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4qf-0003Ux-Db for disman-archive@odin.ietf.org; Tue, 04 Nov 2003 12:20:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4HK9xl013441 for disman-archive@odin.ietf.org; Tue, 4 Nov 2003 12:20:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4qe-0003Ui-VY for disman-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 12:20:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23646 for ; Tue, 4 Nov 2003 12:19:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4qd-00016y-00 for disman-web-archive@ietf.org; Tue, 04 Nov 2003 12:20:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH4qd-00016s-00 for disman-web-archive@ietf.org; Tue, 04 Nov 2003 12:20:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4qZ-0003Tq-Bo; Tue, 04 Nov 2003 12:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4pn-0003S7-To for disman@optimus.ietf.org; Tue, 04 Nov 2003 12:19:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23591; Tue, 4 Nov 2003 12:19:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4pl-00015k-00; Tue, 04 Nov 2003 12:19:13 -0500 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AH4pl-00015f-00; Tue, 04 Nov 2003 12:19:13 -0500 Received: from h-68-165-69-162.snvacaid.dynamic.covad.net ([68.165.69.162] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AH4pj-0006NB-00; Tue, 04 Nov 2003 09:19:11 -0800 Message-ID: <001e01c3a22e$c1fd3ca0$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] changes to MIB IPR boilerplate 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, 3 Nov 2003 09:20:19 -0800 Hi - The IESG has announced a change to the copyright notice that needs to be embedded in MIB MODULE-IDENTITY sections. The change was described in the IESG announcement. The relevant portion follows: > From: "The IESG" > To: > Cc: "Internet Architecture Board" ; "RFC Editor" ; > Sent: Monday, November 03, 2003 12:27 PM > Subject: Protocol Action: 'IETF Rights in Contributions' to BCP ... > RFC EDITOR NOTE: > > In section 5.6 of draft-ietf-ipr-submission-rights, please make the > following changes: > > OLD: > > "Copyright (C) The Internet Society . The initial > version of this MIB module was published in RFC XXXX; for full > legal notices see the RFC itself or see: > http://www.ietf.org/copyrights/ianamib.html." > > NEW: > > "Copyright (C) The Internet Society . The initial > version of this MIB module was published in RFC XXXX; for full > legal notices see the RFC itself. Supplementary information > may be available on http://www.ietf.org/copyrights/ianamib.html." ... Randy From disman-admin@ietf.org Fri Nov 7 22:29:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20740 for ; Fri, 7 Nov 2003 22:29:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJmX-0003iW-6Y; Fri, 07 Nov 2003 22:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJm9-0003iK-Oy for disman@optimus.ietf.org; Fri, 07 Nov 2003 22:28: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 WAA20725 for ; Fri, 7 Nov 2003 22:28:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIJm6-0007k2-00 for disman@ietf.org; Fri, 07 Nov 2003 22:28:34 -0500 Received: from pintail.mail.pas.earthlink.net ([207.217.120.122]) by ietf-mx with esmtp (Exim 4.12) id 1AIJm5-0007jz-00 for disman@ietf.org; Fri, 07 Nov 2003 22:28:34 -0500 Received: from h-68-164-89-128.snvacaid.dynamic.covad.net ([68.164.89.128] helo=oemcomputer) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AIJm5-00016X-00 for disman@ietf.org; Fri, 07 Nov 2003 19:28:33 -0800 Message-ID: <002c01c3a5a8$9195aca0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD34091BBB74@zcard0ka.ca.nortel.com> Subject: Re: [Disman] alarm comment 69-1 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Nov 2003 19:29:50 -0800 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Sunday, November 02, 2003 2:58 AM > Subject: RE: [Disman] alarm comment 69-1 > > hi > > The following is the proposed resolution to Randy-69-1 Assuming no > objection, this item will be considered closed conditional on the > proposed edit being done. > > Replace > > > ituAlarmEntry OBJECT-TYPE > SYNTAX ItuAlarmEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Entries appear in this table for each possible alarm > severity. > This table MUST be persistent across system reboots." > INDEX { alarmListName, alarmModelIndex, > ituAlarmPerceivedSeverity } > ::= { ituAlarmTable 1 } > > With > > > ituAlarmEntry OBJECT-TYPE > SYNTAX ItuAlarmEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Entries appear in this table for each possible alarm > severity. For each entry created/deleted in the > alarmModeTable an entry in this table is created/deleted > with a mapping from alarmModelState to > ituAlarmPerceivedSeverity as follows: > > alarmModelState -> ituAlarmPerceivedSeverity > 1 -> clear (1) > 2 -> indeterminate (2) > 3 -> warning (6) > 4 -> minor (5) > 5 -> major (4) > 6 -> critical (3) > > All other values of alarmModelState MUST NOT appear > in this table. > > This table MUST be persistent across system reboots." > INDEX { alarmListName, alarmModelIndex, > ituAlarmPerceivedSeverity } > ::= { ituAlarmTable 1 } > > Sharon ... Let's see if I understand this correctly. If a system supports the ituAlarmTable, then whenever an entry is created (whether by user or by system) in the alarmModelTabel with an alarmModelState value of 1, 2, 3, 4, 5, or 6, then a corresponding entry will appear in the ituAlarmTable. Likewise, whenever an entry is deleted from the ituAlarmTable, and that entry has an alarmModelState value of 1..6, any corresponding entry will disappear from the ituAlarmTable. So far, so good? Here's my problem: if the system also supports some other extension model which does not necessarily map to the ITU model, then even if that model is able to avoid alarmModelState values of 2, 3, 4, 5, and 6, I don't see how it could avoid using alarmModelState value 1, and consequently ending up with entries in both the ituAlarmTable as well as this other extension table for alarmModelState 1. Do you consider this to be a feature rather than a bug? Randy From exim@www1.ietf.org Fri Nov 7 22:29:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20755 for ; Fri, 7 Nov 2003 22:29: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 1AIJmi-0003jQ-LY for disman-archive@odin.ietf.org; Fri, 07 Nov 2003 22:29:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA83TC4H014340 for disman-archive@odin.ietf.org; Fri, 7 Nov 2003 22:29:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJmi-0003jD-H5 for disman-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 22:29:12 -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 WAA20737 for ; Fri, 7 Nov 2003 22:28:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIJmf-0007kI-00 for disman-web-archive@ietf.org; Fri, 07 Nov 2003 22:29:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIJme-0007kE-00 for disman-web-archive@ietf.org; Fri, 07 Nov 2003 22:29:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJmX-0003iW-6Y; Fri, 07 Nov 2003 22:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJm9-0003iK-Oy for disman@optimus.ietf.org; Fri, 07 Nov 2003 22:28: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 WAA20725 for ; Fri, 7 Nov 2003 22:28:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIJm6-0007k2-00 for disman@ietf.org; Fri, 07 Nov 2003 22:28:34 -0500 Received: from pintail.mail.pas.earthlink.net ([207.217.120.122]) by ietf-mx with esmtp (Exim 4.12) id 1AIJm5-0007jz-00 for disman@ietf.org; Fri, 07 Nov 2003 22:28:34 -0500 Received: from h-68-164-89-128.snvacaid.dynamic.covad.net ([68.164.89.128] helo=oemcomputer) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AIJm5-00016X-00 for disman@ietf.org; Fri, 07 Nov 2003 19:28:33 -0800 Message-ID: <002c01c3a5a8$9195aca0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD34091BBB74@zcard0ka.ca.nortel.com> Subject: Re: [Disman] alarm comment 69-1 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Nov 2003 19:29:50 -0800 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Sunday, November 02, 2003 2:58 AM > Subject: RE: [Disman] alarm comment 69-1 > > hi > > The following is the proposed resolution to Randy-69-1 Assuming no > objection, this item will be considered closed conditional on the > proposed edit being done. > > Replace > > > ituAlarmEntry OBJECT-TYPE > SYNTAX ItuAlarmEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Entries appear in this table for each possible alarm > severity. > This table MUST be persistent across system reboots." > INDEX { alarmListName, alarmModelIndex, > ituAlarmPerceivedSeverity } > ::= { ituAlarmTable 1 } > > With > > > ituAlarmEntry OBJECT-TYPE > SYNTAX ItuAlarmEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Entries appear in this table for each possible alarm > severity. For each entry created/deleted in the > alarmModeTable an entry in this table is created/deleted > with a mapping from alarmModelState to > ituAlarmPerceivedSeverity as follows: > > alarmModelState -> ituAlarmPerceivedSeverity > 1 -> clear (1) > 2 -> indeterminate (2) > 3 -> warning (6) > 4 -> minor (5) > 5 -> major (4) > 6 -> critical (3) > > All other values of alarmModelState MUST NOT appear > in this table. > > This table MUST be persistent across system reboots." > INDEX { alarmListName, alarmModelIndex, > ituAlarmPerceivedSeverity } > ::= { ituAlarmTable 1 } > > Sharon ... Let's see if I understand this correctly. If a system supports the ituAlarmTable, then whenever an entry is created (whether by user or by system) in the alarmModelTabel with an alarmModelState value of 1, 2, 3, 4, 5, or 6, then a corresponding entry will appear in the ituAlarmTable. Likewise, whenever an entry is deleted from the ituAlarmTable, and that entry has an alarmModelState value of 1..6, any corresponding entry will disappear from the ituAlarmTable. So far, so good? Here's my problem: if the system also supports some other extension model which does not necessarily map to the ITU model, then even if that model is able to avoid alarmModelState values of 2, 3, 4, 5, and 6, I don't see how it could avoid using alarmModelState value 1, and consequently ending up with entries in both the ituAlarmTable as well as this other extension table for alarmModelState 1. Do you consider this to be a feature rather than a bug? Randy From disman-admin@ietf.org Sat Nov 8 17:53:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29190 for ; Sat, 8 Nov 2003 17:53:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIbwz-0002HL-8J; Sat, 08 Nov 2003 17:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIbwF-0002Gv-AR for disman@optimus.ietf.org; Sat, 08 Nov 2003 17:52:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29171 for ; Sat, 8 Nov 2003 17:52:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIbwC-000673-00 for disman@ietf.org; Sat, 08 Nov 2003 17:52:12 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1AIbwC-000670-00 for disman@ietf.org; Sat, 08 Nov 2003 17:52:12 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hA8MpcFY009844 for ; Sat, 8 Nov 2003 17:51:38 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hA8MpZFY009836 for ; Sat, 8 Nov 2003 17:51:36 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Disman] alarm comment 69-1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [Disman] alarm comment 69-1 Thread-Index: AcOlqItfep4SciVZQc64N2qbMXVZBAAofL2g From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , "Disman (E-mail)" 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: Sun, 9 Nov 2003 00:52:04 +0200 Content-Transfer-Encoding: quoted-printable > Let's see if I understand this correctly. If a system=20 > supports the ituAlarmTable, > then whenever an entry is created (whether by user or by=20 > system) in the > alarmModelTabel with an alarmModelState value of 1, 2, 3, 4,=20 > 5, or 6, then > a corresponding entry will appear in the ituAlarmTable. =20 > Likewise, whenever > an entry is deleted from the ituAlarmTable, and that entry=20 > has an alarmModelState > value of 1..6, any corresponding entry will disappear from=20 > the ituAlarmTable. > So far, so good? yes. >=20 > Here's my problem: if the system also supports some other=20 > extension model which > does not necessarily map to the ITU model, then even if that=20 > model is able to > avoid alarmModelState values of 2, 3, 4, 5, and 6, I don't=20 > see how it could avoid > using alarmModelState value 1, and consequently ending up=20 > with entries in both > the ituAlarmTable as well as this other extension table for=20 > alarmModelState 1. > Do you consider this to be a feature rather than a bug? A feature. 'A value of 1 (for alarmModelState) MUST indicate a clear = alarm state'. Concurrent specific models MAY support a clear alarm = state.=20 >=20 > Randy >=20 >=20 Dan >=20 >=20 From exim@www1.ietf.org Sat Nov 8 17:53:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29203 for ; Sat, 8 Nov 2003 17:53:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIbx7-0002I9-A0 for disman-archive@odin.ietf.org; Sat, 08 Nov 2003 17:53:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA8Mr9LH008803 for disman-archive@odin.ietf.org; Sat, 8 Nov 2003 17:53:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIbx7-0002Hu-6e for disman-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 17:53:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29177 for ; Sat, 8 Nov 2003 17:52:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIbx4-00067C-00 for disman-web-archive@ietf.org; Sat, 08 Nov 2003 17:53:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIbx3-000679-00 for disman-web-archive@ietf.org; Sat, 08 Nov 2003 17:53:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIbwz-0002HL-8J; Sat, 08 Nov 2003 17:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIbwF-0002Gv-AR for disman@optimus.ietf.org; Sat, 08 Nov 2003 17:52:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29171 for ; Sat, 8 Nov 2003 17:52:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIbwC-000673-00 for disman@ietf.org; Sat, 08 Nov 2003 17:52:12 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1AIbwC-000670-00 for disman@ietf.org; Sat, 08 Nov 2003 17:52:12 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hA8MpcFY009844 for ; Sat, 8 Nov 2003 17:51:38 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hA8MpZFY009836 for ; Sat, 8 Nov 2003 17:51:36 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Disman] alarm comment 69-1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [Disman] alarm comment 69-1 Thread-Index: AcOlqItfep4SciVZQc64N2qbMXVZBAAofL2g From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , "Disman (E-mail)" 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: Sun, 9 Nov 2003 00:52:04 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Let's see if I understand this correctly. If a system=20 > supports the ituAlarmTable, > then whenever an entry is created (whether by user or by=20 > system) in the > alarmModelTabel with an alarmModelState value of 1, 2, 3, 4,=20 > 5, or 6, then > a corresponding entry will appear in the ituAlarmTable. =20 > Likewise, whenever > an entry is deleted from the ituAlarmTable, and that entry=20 > has an alarmModelState > value of 1..6, any corresponding entry will disappear from=20 > the ituAlarmTable. > So far, so good? yes. >=20 > Here's my problem: if the system also supports some other=20 > extension model which > does not necessarily map to the ITU model, then even if that=20 > model is able to > avoid alarmModelState values of 2, 3, 4, 5, and 6, I don't=20 > see how it could avoid > using alarmModelState value 1, and consequently ending up=20 > with entries in both > the ituAlarmTable as well as this other extension table for=20 > alarmModelState 1. > Do you consider this to be a feature rather than a bug? A feature. 'A value of 1 (for alarmModelState) MUST indicate a clear = alarm state'. Concurrent specific models MAY support a clear alarm = state.=20 >=20 > Randy >=20 >=20 Dan >=20 >=20 From disman-admin@ietf.org Sun Nov 9 16:35:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11360 for ; Sun, 9 Nov 2003 16:35:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxD5-00070z-0T; Sun, 09 Nov 2003 16:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxCk-00070O-OU for disman@optimus.ietf.org; Sun, 09 Nov 2003 16:34:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11318 for ; Sun, 9 Nov 2003 16:34:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIxCi-0007YA-00 for disman@ietf.org; Sun, 09 Nov 2003 16:34:40 -0500 Received: from mclean.mail.mindspring.net ([207.69.200.57]) by ietf-mx with esmtp (Exim 4.12) id 1AIxCi-0007Y6-00 for disman@ietf.org; Sun, 09 Nov 2003 16:34:40 -0500 Received: from wamui05.slb.atl.earthlink.net ([192.168.167.43]) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AIxCh-0000ZG-00; Sun, 09 Nov 2003 16:34:39 -0500 Message-ID: <17054723.1068413678263.JavaMail.root@wamui05.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: "Romascanu, Dan (Dan)" , Randy Presuhn , "Disman (E-mail)" Subject: RE: [Disman] alarm comment 69-1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 9 Nov 2003 15:34:38 -0600 (GMT-06:00) Content-Transfer-Encoding: 7bit Hi - > From: "Romascanu, Dan (Dan)" > Sent: Nov 8, 2003 4:52 PM > To: Randy Presuhn , > "Disman (E-mail)" > Subject: RE: [Disman] alarm comment 69-1 ... > A feature. 'A value of 1 (for alarmModelState) MUST indicate a clear alarm state'. > Concurrent specific models MAY support a clear alarm state. ... It'd be very difficult to define an extension model without a clear state, since that notion is built into both the alarmModelTable and the alarmClearTable. Anyway, in a case like this, where there would be entries in both extension tables, to which one would the alarmModelSpecificPointer point? Randy From exim@www1.ietf.org Sun Nov 9 16:35:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11374 for ; Sun, 9 Nov 2003 16:35:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxDA-00073H-BK for disman-archive@odin.ietf.org; Sun, 09 Nov 2003 16:35:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9LZ8TM027101 for disman-archive@odin.ietf.org; Sun, 9 Nov 2003 16:35:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxDA-000732-6c for disman-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 16:35:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11324 for ; Sun, 9 Nov 2003 16:34:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIxD8-0007YH-00 for disman-web-archive@ietf.org; Sun, 09 Nov 2003 16:35:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIxD7-0007YD-00 for disman-web-archive@ietf.org; Sun, 09 Nov 2003 16:35:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxD5-00070z-0T; Sun, 09 Nov 2003 16:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxCk-00070O-OU for disman@optimus.ietf.org; Sun, 09 Nov 2003 16:34:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11318 for ; Sun, 9 Nov 2003 16:34:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIxCi-0007YA-00 for disman@ietf.org; Sun, 09 Nov 2003 16:34:40 -0500 Received: from mclean.mail.mindspring.net ([207.69.200.57]) by ietf-mx with esmtp (Exim 4.12) id 1AIxCi-0007Y6-00 for disman@ietf.org; Sun, 09 Nov 2003 16:34:40 -0500 Received: from wamui05.slb.atl.earthlink.net ([192.168.167.43]) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AIxCh-0000ZG-00; Sun, 09 Nov 2003 16:34:39 -0500 Message-ID: <17054723.1068413678263.JavaMail.root@wamui05.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: "Romascanu, Dan (Dan)" , Randy Presuhn , "Disman (E-mail)" Subject: RE: [Disman] alarm comment 69-1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 9 Nov 2003 15:34:38 -0600 (GMT-06:00) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi - > From: "Romascanu, Dan (Dan)" > Sent: Nov 8, 2003 4:52 PM > To: Randy Presuhn , > "Disman (E-mail)" > Subject: RE: [Disman] alarm comment 69-1 ... > A feature. 'A value of 1 (for alarmModelState) MUST indicate a clear alarm state'. > Concurrent specific models MAY support a clear alarm state. ... It'd be very difficult to define an extension model without a clear state, since that notion is built into both the alarmModelTable and the alarmClearTable. Anyway, in a case like this, where there would be entries in both extension tables, to which one would the alarmModelSpecificPointer point? Randy From disman-admin@ietf.org Mon Nov 10 07:40:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17789 for ; Mon, 10 Nov 2003 07:40:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJBKt-00027A-JI; Mon, 10 Nov 2003 07:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJBKE-00026C-Hy for disman@optimus.ietf.org; Mon, 10 Nov 2003 07:39:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17742 for ; Mon, 10 Nov 2003 07:39:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJBKD-0003vw-00 for disman@ietf.org; Mon, 10 Nov 2003 07:39:21 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AJBKD-0003vt-00 for disman@ietf.org; Mon, 10 Nov 2003 07:39:21 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAACcmS19794 for ; Mon, 10 Nov 2003 07:38:49 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Nov 2003 07:38:49 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340930D81A@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] alarm comment 69-1 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: Mon, 10 Nov 2003 07:38:48 -0500 Hi As Dan indicated, this is a feature. It doesn't matter which one the specific pointer points at. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Sunday, November 09, 2003 4:35 PM To: Romascanu, Dan (Dan); Randy Presuhn; Disman (E-mail) Subject: RE: [Disman] alarm comment 69-1 Hi - > From: "Romascanu, Dan (Dan)" > Sent: Nov 8, 2003 4:52 PM > To: Randy Presuhn , > "Disman (E-mail)" > Subject: RE: [Disman] alarm comment 69-1 ... > A feature. 'A value of 1 (for alarmModelState) MUST indicate a clear > alarm state'. Concurrent specific models MAY support a clear alarm > state. ... It'd be very difficult to define an extension model without a clear state, since that notion is built into both the alarmModelTable and the alarmClearTable. Anyway, in a case like this, where there would be entries in both extension tables, to which one would the alarmModelSpecificPointer point? Randy From exim@www1.ietf.org Mon Nov 10 07:40:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17804 for ; Mon, 10 Nov 2003 07:40:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJBL0-00028C-Fi for disman-archive@odin.ietf.org; Mon, 10 Nov 2003 07:40:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAACeAJu008186 for disman-archive@odin.ietf.org; Mon, 10 Nov 2003 07:40:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJBKz-00027x-Hk for disman-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 07:40:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17771 for ; Mon, 10 Nov 2003 07:39:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJBKy-0003wh-00 for disman-web-archive@ietf.org; Mon, 10 Nov 2003 07:40:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJBKy-0003we-00 for disman-web-archive@ietf.org; Mon, 10 Nov 2003 07:40:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJBKt-00027A-JI; Mon, 10 Nov 2003 07:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJBKE-00026C-Hy for disman@optimus.ietf.org; Mon, 10 Nov 2003 07:39:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17742 for ; Mon, 10 Nov 2003 07:39:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJBKD-0003vw-00 for disman@ietf.org; Mon, 10 Nov 2003 07:39:21 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AJBKD-0003vt-00 for disman@ietf.org; Mon, 10 Nov 2003 07:39:21 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAACcmS19794 for ; Mon, 10 Nov 2003 07:38:49 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Nov 2003 07:38:49 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340930D81A@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] alarm comment 69-1 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: Mon, 10 Nov 2003 07:38:48 -0500 Hi As Dan indicated, this is a feature. It doesn't matter which one the specific pointer points at. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Sunday, November 09, 2003 4:35 PM To: Romascanu, Dan (Dan); Randy Presuhn; Disman (E-mail) Subject: RE: [Disman] alarm comment 69-1 Hi - > From: "Romascanu, Dan (Dan)" > Sent: Nov 8, 2003 4:52 PM > To: Randy Presuhn , > "Disman (E-mail)" > Subject: RE: [Disman] alarm comment 69-1 ... > A feature. 'A value of 1 (for alarmModelState) MUST indicate a clear > alarm state'. Concurrent specific models MAY support a clear alarm > state. ... It'd be very difficult to define an extension model without a clear state, since that notion is built into both the alarmModelTable and the alarmClearTable. Anyway, in a case like this, where there would be entries in both extension tables, to which one would the alarmModelSpecificPointer point? Randy From disman-admin@ietf.org Mon Nov 10 13:18:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03836 for ; Mon, 10 Nov 2003 13:18:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJGbx-0006VL-Lc; Mon, 10 Nov 2003 13:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJGbL-0006UI-L6 for disman@optimus.ietf.org; Mon, 10 Nov 2003 13:17:23 -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 NAA03786 for ; Mon, 10 Nov 2003 13:17:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJGbJ-0001aV-00 for disman@ietf.org; Mon, 10 Nov 2003 13:17:21 -0500 Received: from hall.mail.mindspring.net ([207.69.200.60]) by ietf-mx with esmtp (Exim 4.12) id 1AJGbJ-0001aK-00 for disman@ietf.org; Mon, 10 Nov 2003 13:17:21 -0500 Received: from [192.168.167.46] (helo=wamui08.slb.atl.earthlink.net) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AJGbI-0001t9-00 for disman@ietf.org; Mon, 10 Nov 2003 13:17:20 -0500 Message-ID: <4723553.1068488239953.JavaMail.root@wamui08.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: "Disman (E-mail)" Subject: RE: [Disman] alarm comment 69-1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 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, 10 Nov 2003 12:17:19 -0600 (GMT-06:00) Content-Transfer-Encoding: 7bit Hi - > From: Sharon Chisholm > Sent: Nov 10, 2003 6:38 AM > To: "Disman (E-mail)" > Subject: RE: [Disman] alarm comment 69-1 ... > As Dan indicated, this is a feature. It doesn't matter which one the > specific pointer points at. ... Then I suggest that the DESCRIPTION of the specific pointer should explicitly say that its value doesn't matter. (I assume this is true even if it is set to {0 0}. (Of course, that also begs the question of why the object is needed at all.)) If there are stronger constraints on what values are permitted (e.g., must point to a possible, not-already- existing row in an extension table) then we should be explicit. If there are no constraints, we should also be explicit about that. If the set of permissible values is implementation dependent, then the process by which a management system comes to learn what those values are should be documented. Randy From exim@www1.ietf.org Mon Nov 10 13:18:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03851 for ; Mon, 10 Nov 2003 13:18:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJGc0-0006WO-C9 for disman-archive@odin.ietf.org; Mon, 10 Nov 2003 13:18:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAII4fg025064 for disman-archive@odin.ietf.org; Mon, 10 Nov 2003 13:18:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJGc0-0006WB-5u for disman-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 13:18:04 -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 NAA03825 for ; Mon, 10 Nov 2003 13:17:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJGby-0001bK-00 for disman-web-archive@ietf.org; Mon, 10 Nov 2003 13:18:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJGbx-0001bH-00 for disman-web-archive@ietf.org; Mon, 10 Nov 2003 13:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJGbx-0006VL-Lc; Mon, 10 Nov 2003 13:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJGbL-0006UI-L6 for disman@optimus.ietf.org; Mon, 10 Nov 2003 13:17:23 -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 NAA03786 for ; Mon, 10 Nov 2003 13:17:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJGbJ-0001aV-00 for disman@ietf.org; Mon, 10 Nov 2003 13:17:21 -0500 Received: from hall.mail.mindspring.net ([207.69.200.60]) by ietf-mx with esmtp (Exim 4.12) id 1AJGbJ-0001aK-00 for disman@ietf.org; Mon, 10 Nov 2003 13:17:21 -0500 Received: from [192.168.167.46] (helo=wamui08.slb.atl.earthlink.net) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AJGbI-0001t9-00 for disman@ietf.org; Mon, 10 Nov 2003 13:17:20 -0500 Message-ID: <4723553.1068488239953.JavaMail.root@wamui08.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: "Disman (E-mail)" Subject: RE: [Disman] alarm comment 69-1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 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, 10 Nov 2003 12:17:19 -0600 (GMT-06:00) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi - > From: Sharon Chisholm > Sent: Nov 10, 2003 6:38 AM > To: "Disman (E-mail)" > Subject: RE: [Disman] alarm comment 69-1 ... > As Dan indicated, this is a feature. It doesn't matter which one the > specific pointer points at. ... Then I suggest that the DESCRIPTION of the specific pointer should explicitly say that its value doesn't matter. (I assume this is true even if it is set to {0 0}. (Of course, that also begs the question of why the object is needed at all.)) If there are stronger constraints on what values are permitted (e.g., must point to a possible, not-already- existing row in an extension table) then we should be explicit. If there are no constraints, we should also be explicit about that. If the set of permissible values is implementation dependent, then the process by which a management system comes to learn what those values are should be documented. Randy From disman-admin@ietf.org Mon Nov 10 15:45:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12686 for ; Mon, 10 Nov 2003 15:45:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIuF-0001QM-Cq; Mon, 10 Nov 2003 15:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJItl-0001P7-Cp for disman@optimus.ietf.org; Mon, 10 Nov 2003 15:44:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12656 for ; Mon, 10 Nov 2003 15:44:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJItj-0004Me-00 for disman@ietf.org; Mon, 10 Nov 2003 15:44:31 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AJItj-0004MI-00 for disman@ietf.org; Mon, 10 Nov 2003 15:44:31 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAAKhx401408 for ; Mon, 10 Nov 2003 15:44:00 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Nov 2003 15:44:00 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340930DEAB@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] alarm comment 69-1 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: Mon, 10 Nov 2003 15:43:59 -0500 Hi Well, if we MUST bother specifying something then we should say it should point at the ITU one if it exists. My point was that which ever way the implementation chooses to do things, nothing will break. You seem to be confusing whether an object is useful and how micro-managed its definition needs to be. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Monday, November 10, 2003 1:17 PM To: Disman (E-mail) Subject: RE: [Disman] alarm comment 69-1 Hi - > From: Sharon Chisholm > Sent: Nov 10, 2003 6:38 AM > To: "Disman (E-mail)" > Subject: RE: [Disman] alarm comment 69-1 ... > As Dan indicated, this is a feature. It doesn't matter which one the > specific pointer points at. ... Then I suggest that the DESCRIPTION of the specific pointer should explicitly say that its value doesn't matter. (I assume this is true even if it is set to {0 0}. (Of course, that also begs the question of why the object is needed at all.)) If there are stronger constraints on what values are permitted (e.g., must point to a possible, not-already- existing row in an extension table) then we should be explicit. If there are no constraints, we should also be explicit about that. If the set of permissible values is implementation dependent, then the process by which a management system comes to learn what those values are should be documented. Randy From exim@www1.ietf.org Mon Nov 10 17:04:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12696 for ; Mon, 10 Nov 2003 15:45:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIuI-0001RF-2B for disman-archive@odin.ietf.org; Mon, 10 Nov 2003 15:45:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAKj6sg005524 for disman-archive@odin.ietf.org; Mon, 10 Nov 2003 15:45:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIuH-0001R1-V6 for disman-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 15:45:05 -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 PAA12674 for ; Mon, 10 Nov 2003 15:44:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIuG-0004N3-00 for disman-web-archive@ietf.org; Mon, 10 Nov 2003 15:45:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJIuF-0004N0-00 for disman-web-archive@ietf.org; Mon, 10 Nov 2003 15:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIuF-0001QM-Cq; Mon, 10 Nov 2003 15:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJItl-0001P7-Cp for disman@optimus.ietf.org; Mon, 10 Nov 2003 15:44:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12656 for ; Mon, 10 Nov 2003 15:44:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJItj-0004Me-00 for disman@ietf.org; Mon, 10 Nov 2003 15:44:31 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AJItj-0004MI-00 for disman@ietf.org; Mon, 10 Nov 2003 15:44:31 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAAKhx401408 for ; Mon, 10 Nov 2003 15:44:00 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Nov 2003 15:44:00 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340930DEAB@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] alarm comment 69-1 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: Mon, 10 Nov 2003 15:43:59 -0500 Hi Well, if we MUST bother specifying something then we should say it should point at the ITU one if it exists. My point was that which ever way the implementation chooses to do things, nothing will break. You seem to be confusing whether an object is useful and how micro-managed its definition needs to be. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Monday, November 10, 2003 1:17 PM To: Disman (E-mail) Subject: RE: [Disman] alarm comment 69-1 Hi - > From: Sharon Chisholm > Sent: Nov 10, 2003 6:38 AM > To: "Disman (E-mail)" > Subject: RE: [Disman] alarm comment 69-1 ... > As Dan indicated, this is a feature. It doesn't matter which one the > specific pointer points at. ... Then I suggest that the DESCRIPTION of the specific pointer should explicitly say that its value doesn't matter. (I assume this is true even if it is set to {0 0}. (Of course, that also begs the question of why the object is needed at all.)) If there are stronger constraints on what values are permitted (e.g., must point to a possible, not-already- existing row in an extension table) then we should be explicit. If there are no constraints, we should also be explicit about that. If the set of permissible values is implementation dependent, then the process by which a management system comes to learn what those values are should be documented. Randy From disman-admin@ietf.org Mon Nov 10 17:40:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18309 for ; Mon, 10 Nov 2003 17:40: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 1AJKhb-0002oD-2B; Mon, 10 Nov 2003 17:40:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKhM-0002mt-Ff for disman@optimus.ietf.org; Mon, 10 Nov 2003 17:39:52 -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 RAA18240 for ; Mon, 10 Nov 2003 17:39:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKhJ-0006Mc-00 for disman@ietf.org; Mon, 10 Nov 2003 17:39:49 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AJKhJ-0006MZ-00 for disman@ietf.org; Mon, 10 Nov 2003 17:39:49 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAAMbQJK020498 for ; Mon, 10 Nov 2003 17:37:26 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAAMbOJK020427 for ; Mon, 10 Nov 2003 17:37:25 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] alarm comment 69-1 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [Disman] alarm comment 69-1 Thread-Index: AcOny49wta2xr+A7QR2jyw0YkZuwmAADtczA From: "Romascanu, Dan (Dan)" To: "Sharon Chisholm" , "Disman (E-mail)" 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: Tue, 11 Nov 2003 00:39:44 +0200 Content-Transfer-Encoding: quoted-printable From exim@www1.ietf.org Mon Nov 10 17:40:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18324 for ; Mon, 10 Nov 2003 17:40:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKhp-0002v1-4I for disman-archive@odin.ietf.org; Mon, 10 Nov 2003 17:40:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAMeLFn011213 for disman-archive@odin.ietf.org; Mon, 10 Nov 2003 17:40:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKhp-0002um-17 for disman-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 17:40:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18260 for ; Mon, 10 Nov 2003 17:40:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKhm-0006N8-00 for disman-web-archive@ietf.org; Mon, 10 Nov 2003 17:40:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJKhm-0006N4-00 for disman-web-archive@ietf.org; Mon, 10 Nov 2003 17:40:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKhb-0002oD-2B; Mon, 10 Nov 2003 17:40:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKhM-0002mt-Ff for disman@optimus.ietf.org; Mon, 10 Nov 2003 17:39:52 -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 RAA18240 for ; Mon, 10 Nov 2003 17:39:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKhJ-0006Mc-00 for disman@ietf.org; Mon, 10 Nov 2003 17:39:49 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AJKhJ-0006MZ-00 for disman@ietf.org; Mon, 10 Nov 2003 17:39:49 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAAMbQJK020498 for ; Mon, 10 Nov 2003 17:37:26 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAAMbOJK020427 for ; Mon, 10 Nov 2003 17:37:25 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] alarm comment 69-1 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [Disman] alarm comment 69-1 Thread-Index: AcOny49wta2xr+A7QR2jyw0YkZuwmAADtczA From: "Romascanu, Dan (Dan)" To: "Sharon Chisholm" , "Disman (E-mail)" 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: Tue, 11 Nov 2003 00:39:44 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable From disman-admin@ietf.org Tue Nov 11 13:07:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13893 for ; Tue, 11 Nov 2003 13:07:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcus-0007ZF-JO; Tue, 11 Nov 2003 13:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcuk-0007YE-FJ for disman@optimus.ietf.org; Tue, 11 Nov 2003 13:06:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13876 for ; Tue, 11 Nov 2003 13:06:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcui-0007Lq-00 for disman@ietf.org; Tue, 11 Nov 2003 13:06:52 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AJcui-0007LU-00 for disman@ietf.org; Tue, 11 Nov 2003 13:06:52 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hABI6K106374 for ; Tue, 11 Nov 2003 13:06:20 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Nov 2003 13:06:21 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340939020A@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] alarm comment 69-1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 13:06:17 -0500 Hi So, Dan and I are in agreement that we don't want to over engineer this and that it is the primary responsibly of the additional alarm model to provide any additional mappings that it may require. If there are no further objections, I propose we close this issue with the previously suggested resolution: "The following is the proposed resolution to Randy-69-1 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. Replace ituAlarmEntry OBJECT-TYPE SYNTAX ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table for each possible alarm severity. This table MUST be persistent across system reboots." INDEX { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity } ::= { ituAlarmTable 1 } With ituAlarmEntry OBJECT-TYPE SYNTAX ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table for each possible alarm severity. For each entry created/deleted in the alarmModeTable an entry in this table is created/deleted with a mapping from alarmModelState to ituAlarmPerceivedSeverity as follows: alarmModelState -> ituAlarmPerceivedSeverity 1 -> clear (1) 2 -> indeterminate (2) 3 -> warning (6) 4 -> minor (5) 5 -> major (4) 6 -> critical (3) All other values of alarmModelState MUST NOT appear in this table. This table MUST be persistent across system reboots." INDEX { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity } ::= { ituAlarmTable 1 }" Sharon -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Monday, November 10, 2003 5:40 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; Disman (E-mail) Subject: RE: [Disman] alarm comment 69-1 From exim@www1.ietf.org Tue Nov 11 13:07:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13908 for ; Tue, 11 Nov 2003 13:07:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcuv-0007au-T3 for disman-archive@odin.ietf.org; Tue, 11 Nov 2003 13:07:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABI75i8029184 for disman-archive@odin.ietf.org; Tue, 11 Nov 2003 13:07:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcuv-0007ad-7A for disman-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 13:07:05 -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 NAA13884 for ; Tue, 11 Nov 2003 13:06:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcut-0007M4-00 for disman-web-archive@ietf.org; Tue, 11 Nov 2003 13:07:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJcus-0007M1-00 for disman-web-archive@ietf.org; Tue, 11 Nov 2003 13:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcus-0007ZF-JO; Tue, 11 Nov 2003 13:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcuk-0007YE-FJ for disman@optimus.ietf.org; Tue, 11 Nov 2003 13:06:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13876 for ; Tue, 11 Nov 2003 13:06:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcui-0007Lq-00 for disman@ietf.org; Tue, 11 Nov 2003 13:06:52 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AJcui-0007LU-00 for disman@ietf.org; Tue, 11 Nov 2003 13:06:52 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hABI6K106374 for ; Tue, 11 Nov 2003 13:06:20 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Nov 2003 13:06:21 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340939020A@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] alarm comment 69-1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 13:06:17 -0500 Hi So, Dan and I are in agreement that we don't want to over engineer this and that it is the primary responsibly of the additional alarm model to provide any additional mappings that it may require. If there are no further objections, I propose we close this issue with the previously suggested resolution: "The following is the proposed resolution to Randy-69-1 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. Replace ituAlarmEntry OBJECT-TYPE SYNTAX ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table for each possible alarm severity. This table MUST be persistent across system reboots." INDEX { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity } ::= { ituAlarmTable 1 } With ituAlarmEntry OBJECT-TYPE SYNTAX ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table for each possible alarm severity. For each entry created/deleted in the alarmModeTable an entry in this table is created/deleted with a mapping from alarmModelState to ituAlarmPerceivedSeverity as follows: alarmModelState -> ituAlarmPerceivedSeverity 1 -> clear (1) 2 -> indeterminate (2) 3 -> warning (6) 4 -> minor (5) 5 -> major (4) 6 -> critical (3) All other values of alarmModelState MUST NOT appear in this table. This table MUST be persistent across system reboots." INDEX { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity } ::= { ituAlarmTable 1 }" Sharon -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Monday, November 10, 2003 5:40 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; Disman (E-mail) Subject: RE: [Disman] alarm comment 69-1 From disman-admin@ietf.org Tue Nov 11 13:25:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14345 for ; Tue, 11 Nov 2003 13:25:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdCG-0000f3-Gk; Tue, 11 Nov 2003 13:25:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdBQ-0000an-DX for disman@optimus.ietf.org; Tue, 11 Nov 2003 13:24:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14291 for ; Tue, 11 Nov 2003 13:23:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdBO-0007VJ-00 for disman@ietf.org; Tue, 11 Nov 2003 13:24:06 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AJdBN-0007Up-00 for disman@ietf.org; Tue, 11 Nov 2003 13:24:05 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hABINY108091 for ; Tue, 11 Nov 2003 13:23:34 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Nov 2003 13:23:35 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409390249@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] "table wrapping" in alarm MIB -15- MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 13:23:33 -0500 Hi The following is the proposed resolution to Randy-75-4 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the definition of alarmActiveEntry replace "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared." With "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared. If under extreme resource constraint the system is unable to add any more entries into this table, then the alarmActiveOverflow statistic will be increased by one." Add new item alarmActiveOverflow OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of active alarms that have not been put into the alarmActiveTable since system restart as a result of extreme resource constraints." ::= { alarmActive 5 } Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 21, 2003 11:14 PM To: Disman (E-mail) Subject: Re: [Disman] "table wrapping" in alarm MIB -15- Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Tuesday, October 21, 2003 7:30 PM > Subject: RE: [Disman] "table wrapping" in alarm MIB -15- ... > I think we are in danger of fundamentally changing the architecture of > this 'active alarm' list for the sake of a corner case. It's not like > we didn't think of this, but rather that we didn't want an > architecture that encouraged partial active alarm lists. > > What exactly is the wg chair looking for with this? ... The chair wants the guy the AD asked to review the document to be happy. He'd like text that says what happens when an alarm model entry matches a notification delivered to the alarm inrastructure, and there is not sufficient storage (or other resources) available to create a new alarm entry. Possibilities: - no alarm entry is created - some alarm entry is deleted or cleared to make room (algorithm needs to be spelled out) - something records that this has happened My personal opinion is that creating no entry, and recording that fact in a counter is probably a reasonable solution, but am open to other possibilities. We went through the design issues in the log MIB. I suspect the tradeoffs are very similar here. This reviewer will be happy as long as the MIB is explicit about what happens; I think this MIB's proponents will figure out what the best thing would be to do when storage is exhausted. I agree that it's desirable to not encourage partial active alarm lists, but I also want *realistic* standards, i.e., no assumptions that storage is infinite. Randy (In all his roles. :-) From exim@www1.ietf.org Tue Nov 11 13:25:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14360 for ; Tue, 11 Nov 2003 13:25:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdCJ-0000gn-Mb for disman-archive@odin.ietf.org; Tue, 11 Nov 2003 13:25:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABIP3gq002643 for disman-archive@odin.ietf.org; Tue, 11 Nov 2003 13:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdCJ-0000fi-JO for disman-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 13:25:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14341 for ; Tue, 11 Nov 2003 13:24:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdCF-0007Vs-00 for disman-web-archive@ietf.org; Tue, 11 Nov 2003 13:24:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJdCF-0007Vm-00 for disman-web-archive@ietf.org; Tue, 11 Nov 2003 13:24:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdCG-0000f3-Gk; Tue, 11 Nov 2003 13:25:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdBQ-0000an-DX for disman@optimus.ietf.org; Tue, 11 Nov 2003 13:24:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14291 for ; Tue, 11 Nov 2003 13:23:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdBO-0007VJ-00 for disman@ietf.org; Tue, 11 Nov 2003 13:24:06 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AJdBN-0007Up-00 for disman@ietf.org; Tue, 11 Nov 2003 13:24:05 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hABINY108091 for ; Tue, 11 Nov 2003 13:23:34 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Nov 2003 13:23:35 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409390249@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] "table wrapping" in alarm MIB -15- MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 13:23:33 -0500 Hi The following is the proposed resolution to Randy-75-4 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the definition of alarmActiveEntry replace "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared." With "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared. If under extreme resource constraint the system is unable to add any more entries into this table, then the alarmActiveOverflow statistic will be increased by one." Add new item alarmActiveOverflow OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of active alarms that have not been put into the alarmActiveTable since system restart as a result of extreme resource constraints." ::= { alarmActive 5 } Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 21, 2003 11:14 PM To: Disman (E-mail) Subject: Re: [Disman] "table wrapping" in alarm MIB -15- Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Tuesday, October 21, 2003 7:30 PM > Subject: RE: [Disman] "table wrapping" in alarm MIB -15- ... > I think we are in danger of fundamentally changing the architecture of > this 'active alarm' list for the sake of a corner case. It's not like > we didn't think of this, but rather that we didn't want an > architecture that encouraged partial active alarm lists. > > What exactly is the wg chair looking for with this? ... The chair wants the guy the AD asked to review the document to be happy. He'd like text that says what happens when an alarm model entry matches a notification delivered to the alarm inrastructure, and there is not sufficient storage (or other resources) available to create a new alarm entry. Possibilities: - no alarm entry is created - some alarm entry is deleted or cleared to make room (algorithm needs to be spelled out) - something records that this has happened My personal opinion is that creating no entry, and recording that fact in a counter is probably a reasonable solution, but am open to other possibilities. We went through the design issues in the log MIB. I suspect the tradeoffs are very similar here. This reviewer will be happy as long as the MIB is explicit about what happens; I think this MIB's proponents will figure out what the best thing would be to do when storage is exhausted. I agree that it's desirable to not encourage partial active alarm lists, but I also want *realistic* standards, i.e., no assumptions that storage is infinite. Randy (In all his roles. :-) From disman-admin@ietf.org Tue Nov 11 13:46:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15068 for ; Tue, 11 Nov 2003 13:46:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdWa-0001g5-Qu; Tue, 11 Nov 2003 13:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdVo-0001Y0-AE for disman@optimus.ietf.org; Tue, 11 Nov 2003 13:45:12 -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 NAA14944 for ; Tue, 11 Nov 2003 13:45:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdVl-0007kb-00 for disman@ietf.org; Tue, 11 Nov 2003 13:45:10 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AJdVk-0007jX-00 for disman@ietf.org; Tue, 11 Nov 2003 13:45:08 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hABIibY26958 for ; Tue, 11 Nov 2003 13:44:37 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Nov 2003 13:44:37 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34093902A2@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Security considerations in draft-ietf-disman-alarm-m ib-15.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 13:44:34 -0500 Hi The following is the proposed resolution to 75-2. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. Add the following text to the security considerations section. " Setting these objects may have disruptive effects on network operation by the flooding of unwanted alarm notifications from the network. It is possible to define multiple alarm that are triggered from the same frequently occurring internal stimulus and uses the alarmActiveState notification to inform interested managers. Since it is not possible to delete alarm models when it has active alarms, and the defined alarm throttling mechanism is limited to a single alarm, this could result in a continuous stream alarm notifications that there is no mechanism defined within this memo to control." Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, October 08, 2003 4:09 PM To: Disman (E-mail) Cc: Randy Presuhn Subject: RE: [Disman] Security considerations in draft-ietf-disman-alarm-m ib-15.txt Hi While I understand how the ARC MIB could be used to cause the problems that the IESG was concerned with, I don't really see where the Alarm MIB poses any more risk than 'normal' notifications. Ok. Let me put on my imagination hat: if a manager somehow sets up 323432 alarm models that alarm on the same internal stimulus and use the Alarm MIB notifications and then makes that internal stimulus happen, then 323432 notifications will get sent out on the wire. Is this what we are trying to warn people against? Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 3:58 PM To: Disman (E-mail) Subject: Re: [Disman] Security considerations in draft-ietf-disman-alarm-mib-15.txt Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 12:48 PM > Subject: RE: [Disman] Security considerations in > draft-ietf-disman-alarm-mib-15.txt .. > The following is the proposed resolution to Randy-75-2. Assuming no > objection, this item will is closed with no changes to the draft. I object, both as WG chair and as a technical contributor. > Assuming you referring to the following text: > > " Setting these objects may have disruptive effects on network > operation that range from omission of alarm notifications to > flooding of unwanted alarm notifications from the network. > The consequence of suppressing or deferring the reporting > of an alarm can prevent the timely delivery of important > diagnostic information, including information that can help > identify an attack." > > This is not relevant in the case of the Alarm MIB since we neither > suppress or defer notifications. We have text about throttling in the > 'normal' places within the draft. Technically: Even with the throttling language that's there, this MIB can be used to cause flooding, either due to an exessive number of resources going into alarm (throttling is in part per resource type), oscillating (throttling is on consecutive notifications), or distributed DoS (multiple systems configured). As Chair: Given the IESG's comments on the ARC MIB, which show that they are well aware of these issues, I believe we need to reconsider. Randy From exim@www1.ietf.org Tue Nov 11 13:46:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15088 for ; Tue, 11 Nov 2003 13:46:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdWd-0001hc-NB for disman-archive@odin.ietf.org; Tue, 11 Nov 2003 13:46:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABIk3IM006543 for disman-archive@odin.ietf.org; Tue, 11 Nov 2003 13:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdWd-0001gb-Js for disman-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 13:46:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15022 for ; Tue, 11 Nov 2003 13:45:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdWZ-00000k-00 for disman-web-archive@ietf.org; Tue, 11 Nov 2003 13:45:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJdWZ-00000h-00 for disman-web-archive@ietf.org; Tue, 11 Nov 2003 13:45:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdWa-0001g5-Qu; Tue, 11 Nov 2003 13:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdVo-0001Y0-AE for disman@optimus.ietf.org; Tue, 11 Nov 2003 13:45:12 -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 NAA14944 for ; Tue, 11 Nov 2003 13:45:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdVl-0007kb-00 for disman@ietf.org; Tue, 11 Nov 2003 13:45:10 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AJdVk-0007jX-00 for disman@ietf.org; Tue, 11 Nov 2003 13:45:08 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hABIibY26958 for ; Tue, 11 Nov 2003 13:44:37 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Nov 2003 13:44:37 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34093902A2@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Security considerations in draft-ietf-disman-alarm-m ib-15.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 13:44:34 -0500 Hi The following is the proposed resolution to 75-2. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. Add the following text to the security considerations section. " Setting these objects may have disruptive effects on network operation by the flooding of unwanted alarm notifications from the network. It is possible to define multiple alarm that are triggered from the same frequently occurring internal stimulus and uses the alarmActiveState notification to inform interested managers. Since it is not possible to delete alarm models when it has active alarms, and the defined alarm throttling mechanism is limited to a single alarm, this could result in a continuous stream alarm notifications that there is no mechanism defined within this memo to control." Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, October 08, 2003 4:09 PM To: Disman (E-mail) Cc: Randy Presuhn Subject: RE: [Disman] Security considerations in draft-ietf-disman-alarm-m ib-15.txt Hi While I understand how the ARC MIB could be used to cause the problems that the IESG was concerned with, I don't really see where the Alarm MIB poses any more risk than 'normal' notifications. Ok. Let me put on my imagination hat: if a manager somehow sets up 323432 alarm models that alarm on the same internal stimulus and use the Alarm MIB notifications and then makes that internal stimulus happen, then 323432 notifications will get sent out on the wire. Is this what we are trying to warn people against? Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 3:58 PM To: Disman (E-mail) Subject: Re: [Disman] Security considerations in draft-ietf-disman-alarm-mib-15.txt Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 12:48 PM > Subject: RE: [Disman] Security considerations in > draft-ietf-disman-alarm-mib-15.txt .. > The following is the proposed resolution to Randy-75-2. Assuming no > objection, this item will is closed with no changes to the draft. I object, both as WG chair and as a technical contributor. > Assuming you referring to the following text: > > " Setting these objects may have disruptive effects on network > operation that range from omission of alarm notifications to > flooding of unwanted alarm notifications from the network. > The consequence of suppressing or deferring the reporting > of an alarm can prevent the timely delivery of important > diagnostic information, including information that can help > identify an attack." > > This is not relevant in the case of the Alarm MIB since we neither > suppress or defer notifications. We have text about throttling in the > 'normal' places within the draft. Technically: Even with the throttling language that's there, this MIB can be used to cause flooding, either due to an exessive number of resources going into alarm (throttling is in part per resource type), oscillating (throttling is on consecutive notifications), or distributed DoS (multiple systems configured). As Chair: Given the IESG's comments on the ARC MIB, which show that they are well aware of these issues, I believe we need to reconsider. Randy From disman-admin@ietf.org Tue Nov 11 13:57:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15528 for ; Tue, 11 Nov 2003 13:57:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdhE-0002b2-Ps; Tue, 11 Nov 2003 13:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdgK-0002Yu-EA for disman@optimus.ietf.org; Tue, 11 Nov 2003 13:56:04 -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 NAA15483 for ; Tue, 11 Nov 2003 13:55:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdgI-0000Al-00 for disman@ietf.org; Tue, 11 Nov 2003 13:56:02 -0500 Received: from mclean.mail.mindspring.net ([207.69.200.57]) by ietf-mx with esmtp (Exim 4.12) id 1AJdgH-0000Ai-00 for disman@ietf.org; Tue, 11 Nov 2003 13:56:01 -0500 Received: from wamui04.slb.atl.earthlink.net ([192.168.167.42]) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AJdgH-0003L4-00 for disman@ietf.org; Tue, 11 Nov 2003 13:56:01 -0500 Message-ID: <22644604.1068576960636.JavaMail.root@wamui04.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Subject: RE: [Disman] alarm comment 69-1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 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: Tue, 11 Nov 2003 12:56:00 -0600 (GMT-06:00) Content-Transfer-Encoding: 7bit Hi - As technical contributor: Although I *really* dislike the amount of magic this requires, in the interest of getting this thing out, I'm willing to give up on this issue *if* the language is tightened up *and* the constraints on alarmModelSpecificPointer are spelled out. Specific changes I'd like to see to the proposal: ituAlarmEntry OBJECT-TYPE SYNTAX ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table whenever an entry is created in the alarmModelTable with a value of alarmModelState in the range from 1 to 6. Entries disappear from this table whenever the corresponding entries are deleted from the alarmModelTable, including in cases where those entries have been deleted due to local system action. The value of alarmModelSpecificPointer has no effect on the creation or deletion of entries in this table. Values of alarmModelState map to values of ituAlarmPerceivedSeverity as follows: alarmModelState -> ituAlarmPerceivedSeverity 1 -> clear (1) 2 -> indeterminate (2) 3 -> warning (6) 4 -> minor (5) 5 -> major (4) 6 -> critical (3) Any other values of alarmModelState MUST NOT appear in this table, since the SYNTAX of ituAlarmPerceivedSeverity is limited to this range. This table MUST be persistent across system reboots, but this persistence MUST NOT result in a situation in which an entry exists in this table without a corresponding entry in the alarmModelTable." INDEX { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity } ::= { ituAlarmTable 1 }" Likewise, if we're going to go with this approach, I'd like to see the DESCRIPTION of alarmModelSpecificPointer clarified to say something like: "If no additional, model-specific Alarm MIB is supported by the system, the value of this object MUST be { 0 0 }, and attempts to set it to any other value MUST be rejected appropriately. If the system does support one or more model-specific Alarm MIBs, then, if creation of this row would result in creation of a row in one or more model-specific alarm MIBs, the value to which this object is set MUST refer to the first accessible object in a corresponding row of the model definition in one of these model-specific MIBs; attempts to set this object to { 0 0 } or any other value MUST be rejected appropriately. When a model-specific Alarm MIB is supported, this object is the instance pointer to the model-specific alarm definition." As WG chair: These words could use some polish, but we do need to make a serious attempt to ensure that our definitions are sufficiently precise to make interoperation of implementations reasonably likely. The semantics Randy spelled out were his *guess* as to what the current i-d intended. If he got it wrong, that's just one more reason to make the intent *clear* and *explicit*. Randy From exim@www1.ietf.org Tue Nov 11 13:57:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15543 for ; Tue, 11 Nov 2003 13:57:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdhH-0002bo-1g for disman-archive@odin.ietf.org; Tue, 11 Nov 2003 13:57:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABIv3T1010022 for disman-archive@odin.ietf.org; Tue, 11 Nov 2003 13:57:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdhG-0002bZ-Te for disman-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 13:57:02 -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 NAA15520 for ; Tue, 11 Nov 2003 13:56:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdhE-0000BD-00 for disman-web-archive@ietf.org; Tue, 11 Nov 2003 13:57:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJdhE-0000BA-00 for disman-web-archive@ietf.org; Tue, 11 Nov 2003 13:57:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdhE-0002b2-Ps; Tue, 11 Nov 2003 13:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdgK-0002Yu-EA for disman@optimus.ietf.org; Tue, 11 Nov 2003 13:56:04 -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 NAA15483 for ; Tue, 11 Nov 2003 13:55:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdgI-0000Al-00 for disman@ietf.org; Tue, 11 Nov 2003 13:56:02 -0500 Received: from mclean.mail.mindspring.net ([207.69.200.57]) by ietf-mx with esmtp (Exim 4.12) id 1AJdgH-0000Ai-00 for disman@ietf.org; Tue, 11 Nov 2003 13:56:01 -0500 Received: from wamui04.slb.atl.earthlink.net ([192.168.167.42]) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AJdgH-0003L4-00 for disman@ietf.org; Tue, 11 Nov 2003 13:56:01 -0500 Message-ID: <22644604.1068576960636.JavaMail.root@wamui04.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Subject: RE: [Disman] alarm comment 69-1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 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: Tue, 11 Nov 2003 12:56:00 -0600 (GMT-06:00) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi - As technical contributor: Although I *really* dislike the amount of magic this requires, in the interest of getting this thing out, I'm willing to give up on this issue *if* the language is tightened up *and* the constraints on alarmModelSpecificPointer are spelled out. Specific changes I'd like to see to the proposal: ituAlarmEntry OBJECT-TYPE SYNTAX ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table whenever an entry is created in the alarmModelTable with a value of alarmModelState in the range from 1 to 6. Entries disappear from this table whenever the corresponding entries are deleted from the alarmModelTable, including in cases where those entries have been deleted due to local system action. The value of alarmModelSpecificPointer has no effect on the creation or deletion of entries in this table. Values of alarmModelState map to values of ituAlarmPerceivedSeverity as follows: alarmModelState -> ituAlarmPerceivedSeverity 1 -> clear (1) 2 -> indeterminate (2) 3 -> warning (6) 4 -> minor (5) 5 -> major (4) 6 -> critical (3) Any other values of alarmModelState MUST NOT appear in this table, since the SYNTAX of ituAlarmPerceivedSeverity is limited to this range. This table MUST be persistent across system reboots, but this persistence MUST NOT result in a situation in which an entry exists in this table without a corresponding entry in the alarmModelTable." INDEX { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity } ::= { ituAlarmTable 1 }" Likewise, if we're going to go with this approach, I'd like to see the DESCRIPTION of alarmModelSpecificPointer clarified to say something like: "If no additional, model-specific Alarm MIB is supported by the system, the value of this object MUST be { 0 0 }, and attempts to set it to any other value MUST be rejected appropriately. If the system does support one or more model-specific Alarm MIBs, then, if creation of this row would result in creation of a row in one or more model-specific alarm MIBs, the value to which this object is set MUST refer to the first accessible object in a corresponding row of the model definition in one of these model-specific MIBs; attempts to set this object to { 0 0 } or any other value MUST be rejected appropriately. When a model-specific Alarm MIB is supported, this object is the instance pointer to the model-specific alarm definition." As WG chair: These words could use some polish, but we do need to make a serious attempt to ensure that our definitions are sufficiently precise to make interoperation of implementations reasonably likely. The semantics Randy spelled out were his *guess* as to what the current i-d intended. If he got it wrong, that's just one more reason to make the intent *clear* and *explicit*. Randy From disman-admin@ietf.org Tue Nov 11 14:25:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16432 for ; Tue, 11 Nov 2003 14:25:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe8M-0004fX-MT; Tue, 11 Nov 2003 14:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe7e-0004eq-CD for disman@optimus.ietf.org; Tue, 11 Nov 2003 14:24:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16387 for ; Tue, 11 Nov 2003 14:24:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJe7b-0000Ui-00 for disman@ietf.org; Tue, 11 Nov 2003 14:24:15 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AJe7a-0000U5-00 for disman@ietf.org; Tue, 11 Nov 2003 14:24:15 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hABJNhY09635 for ; Tue, 11 Nov 2003 14:23:43 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Nov 2003 14:23:43 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340939034A@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] unthrottleable alarm state change notifications MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 14:23:41 -0500 Hi The following is the proposed resolution to Randy-55. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the description of alarmModelRowStatus replace " This row can not be modified or deleted while it is being referenced by a value of alarmActiveModelPointer. In these cases, an error of `inconsistentValue' will be returned to the manager." With " This row can not be modified while it is being referenced by a value of alarmActiveModelPointer. In these cases, an error of `inconsistentValue' will be returned to the manager. This entry may be deleted while it is being referenced by a value of alarmActiveModelPointer. This results in the deletion of this entry and entries in the active alarms referencing this entry via a alarmActiveModelPointer." Add the following text to the security considerations section "Changing values of alarmModelRowStatus as part of creating and deleting rows in the alarmModelTable result in adding new alarm models to the system or taking them out respectively. These operations need to be carefully planned. Adding a new model should be made in a consistent manner to avoid the system overflow with alarms. Taking out a model should result in the deletion of all this model related alarms in the system." Which I guess results in the following change to the text proposed to resolve Randy-75-2 Replace " Setting these objects may have disruptive effects on network operation by the flooding of unwanted alarm notifications from the network. It is possible to define multiple alarm that are triggered from the same frequently occurring internal stimulus and uses the alarmActiveState notification to inform interested managers. Since it is not possible to delete alarm models when it has active alarms, and the defined alarm throttling mechanism is limited to a single alarm, this could result in a continuous stream alarm notifications that there is no mechanism defined within this memo to control." With " Note that the alarm throttling mechanism associated with the alarmActiveState and alarmActiveClear notifications only applies to a given alarm. Defining multiple alarms from the same internal stimulus may then still result in a flood of alarms into the network." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 23, 2003 1:48 PM To: Disman (E-mail) Subject: Re: [Disman] unthrottleable alarm state change notifications Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > > Sent: Thursday, October 23, 2003 6:27 AM > Subject: RE: [Disman] unthrottleable alarm state change notifications ... > Yes. In general the text in the security considerations should be more > detailed in explaining the implications of performing write operations > on the read-write or read-create objects. For example in this case: > > 'Changes values of alarmModelRowStatus as part of creating and > deleting rows in the alarmModelTable result in adding new alarm models > to the system or taking them out. These operations need to be > carefully planned. Adding a new model should be made in a consistent > manner to avoid the system overflow with alarms. Taking out a model > should result in the deletion of all this model related alarms in the > system.' I like this a lot, though I think the last "should" should be a "MUST". I expect Sharon will wordsmith it into shape, if no one objects to it. Randy From exim@www1.ietf.org Tue Nov 11 14:25:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16451 for ; Tue, 11 Nov 2003 14:25:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe8P-0004gr-Il for disman-archive@odin.ietf.org; Tue, 11 Nov 2003 14:25:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABJP5NV018023 for disman-archive@odin.ietf.org; Tue, 11 Nov 2003 14:25:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe8P-0004gc-Dm for disman-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 14:25:05 -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 OAA16414 for ; Tue, 11 Nov 2003 14:24:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJe8M-0000VL-00 for disman-web-archive@ietf.org; Tue, 11 Nov 2003 14:25:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJe8M-0000VI-00 for disman-web-archive@ietf.org; Tue, 11 Nov 2003 14:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe8M-0004fX-MT; Tue, 11 Nov 2003 14:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe7e-0004eq-CD for disman@optimus.ietf.org; Tue, 11 Nov 2003 14:24:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16387 for ; Tue, 11 Nov 2003 14:24:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJe7b-0000Ui-00 for disman@ietf.org; Tue, 11 Nov 2003 14:24:15 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AJe7a-0000U5-00 for disman@ietf.org; Tue, 11 Nov 2003 14:24:15 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hABJNhY09635 for ; Tue, 11 Nov 2003 14:23:43 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Nov 2003 14:23:43 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340939034A@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] unthrottleable alarm state change notifications MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 14:23:41 -0500 Hi The following is the proposed resolution to Randy-55. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the description of alarmModelRowStatus replace " This row can not be modified or deleted while it is being referenced by a value of alarmActiveModelPointer. In these cases, an error of `inconsistentValue' will be returned to the manager." With " This row can not be modified while it is being referenced by a value of alarmActiveModelPointer. In these cases, an error of `inconsistentValue' will be returned to the manager. This entry may be deleted while it is being referenced by a value of alarmActiveModelPointer. This results in the deletion of this entry and entries in the active alarms referencing this entry via a alarmActiveModelPointer." Add the following text to the security considerations section "Changing values of alarmModelRowStatus as part of creating and deleting rows in the alarmModelTable result in adding new alarm models to the system or taking them out respectively. These operations need to be carefully planned. Adding a new model should be made in a consistent manner to avoid the system overflow with alarms. Taking out a model should result in the deletion of all this model related alarms in the system." Which I guess results in the following change to the text proposed to resolve Randy-75-2 Replace " Setting these objects may have disruptive effects on network operation by the flooding of unwanted alarm notifications from the network. It is possible to define multiple alarm that are triggered from the same frequently occurring internal stimulus and uses the alarmActiveState notification to inform interested managers. Since it is not possible to delete alarm models when it has active alarms, and the defined alarm throttling mechanism is limited to a single alarm, this could result in a continuous stream alarm notifications that there is no mechanism defined within this memo to control." With " Note that the alarm throttling mechanism associated with the alarmActiveState and alarmActiveClear notifications only applies to a given alarm. Defining multiple alarms from the same internal stimulus may then still result in a flood of alarms into the network." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 23, 2003 1:48 PM To: Disman (E-mail) Subject: Re: [Disman] unthrottleable alarm state change notifications Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > > Sent: Thursday, October 23, 2003 6:27 AM > Subject: RE: [Disman] unthrottleable alarm state change notifications ... > Yes. In general the text in the security considerations should be more > detailed in explaining the implications of performing write operations > on the read-write or read-create objects. For example in this case: > > 'Changes values of alarmModelRowStatus as part of creating and > deleting rows in the alarmModelTable result in adding new alarm models > to the system or taking them out. These operations need to be > carefully planned. Adding a new model should be made in a consistent > manner to avoid the system overflow with alarms. Taking out a model > should result in the deletion of all this model related alarms in the > system.' I like this a lot, though I think the last "should" should be a "MUST". I expect Sharon will wordsmith it into shape, if no one objects to it. Randy From disman-admin@ietf.org Tue Nov 11 14:38:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17488 for ; Tue, 11 Nov 2003 14:38:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeKv-0006XX-8l; Tue, 11 Nov 2003 14:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeKi-0006Tz-3s for disman@optimus.ietf.org; Tue, 11 Nov 2003 14:37:48 -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 OAA17453 for ; Tue, 11 Nov 2003 14:37:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJeKf-0000oX-00 for disman@ietf.org; Tue, 11 Nov 2003 14:37:45 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AJeKe-0000o6-00 for disman@ietf.org; Tue, 11 Nov 2003 14:37:44 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hABJbD122824 for ; Tue, 11 Nov 2003 14:37:13 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Nov 2003 14:37:13 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409390375@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] varbind offsets in alarm-mib-15 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 14:37:13 -0500 Hi The following is the proposed resolution to Randy-47. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 3.6, replace "The varbind reference approach taken in the Alarm MIB is that, for variables such as the alarmModelVarbindIndex, the first two obligatory varbinds of the InformRequest-PDU and SNMPv2-Trap-PDU are ignored, and the index aligns with the Trap-PDU and the SMI. In the case of linkDown, the first varbind would always be ifIndex." With "The varbind reference approach taken in the Alarm MIB is that, for variables such as the alarmModelVarbindIndex, the first two obligatory varbinds of the InformRequest-PDU and SNMPv2-Trap-PDU need to be considered so the index values of the Trap-PDU and the SMI need be adjusted by two. In the case of linkDown, the third varbind would always be ifIndex." In the description of alarmModelVarbindIndex replace " Note that the value of alarmModelVarbindIndex ignores the existence of the first two obligatory varbinds in the InformRequest-PDU and SNMPv2-Trap-PDU (sysUpTime.0 and snmpTrapOID.0). That is, a value of 1 refers to the first varbind after snmpTrapOID.0. If the incoming notification is instead an SNMPv1 Trap-PDU, then a value of 1 refers to the first varbind" With " Note that the value of alarmModelVarbindIndex acknowledges the existence of the first two obligatory varbinds in the InformRequest-PDU and SNMPv2-Trap-PDU (sysUpTime.0 and snmpTrapOID.0). That is, a value of 2 refers to the snmpTrapOID.0. If the incoming notification is instead an SNMPv1 Trap-PDU, then an appropriate value for sysUpTime.0 or snmpTrapOID.0 shall be determined by using the rules in section 3.1 of [RFC3584]" Also make any necessary changes to the examples in section 6. Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, October 22, 2003 8:40 AM To: Disman (E-mail) Subject: RE: [Disman] varbind offsets in alarm-mib-15 Hi I think it is somewhat dubious to consider working group consensus as the opinion of two people who reviewed the design long after working group last call, but if no one else objects I guess we can change the design. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 21, 2003 8:30 PM To: Disman (E-mail) Cc: Bert Wijnen Subject: Re: [Disman] varbind offsets in alarm-mib-15 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Saturday, October 18, 2003 10:57 AM > Subject: RE: [Disman] varbind offsets in alarm-mib-15 ... > Working group consensus was to translate from v1 traps to > Notifications, which is what we did for storage. I've just looked at > the discussion in the archive. I disagree (with your conclusion, not that you've looked at the archive :-) The consensus was to use the RFC 2576 approach to normalizing the payload into the SNMPv2 form. Which SMI was used to define the PDU that arrived is irrelevant, and may even be unknowable. The first varbind in the PDU should be number one. To assign any other number to the first varbind in the PDU would seem highly questionable, as it would seem highly questionable to claim that any other varbind should be called number one. > Subsequent discussion, and this is more from memory, talked about > designing alarm models and discussed the fact that people would be > designing them off the SMI, not the bits on the wire so it might be > confusing to include the sysUptime and trap OID in the numbering. I > remember Dave Partain saying something along the lines that he didn't > care which way it was done so long as it was properly explained in the > ID. I proposed the method in the current draft and I don't remember > any objections. ... Objections came from me and from Harrie Hazewinkel, whom I've quoted in previous discussions. This argument has been going on since Spring of 2002. I've seen no significant support for the position Sharon has advocated. As WG chair, I'm ruling that the consensus stands: the varbind lists should be handled v2-style, so that index value one refers to the first variable binding in the v2-formatted PDU. If the PDU came from some other protocol or mechanism, e.g., SNMPv1, then the RFC 2576 rules for mapping it into an SNMPv2-style PDU apply. If anyone thinks I have made this ruling in error, on either process or technical grounds, the applicable appeals process is described in RFC 2026 section 6.5.1. Randy Disman WG chair From exim@www1.ietf.org Tue Nov 11 14:38:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17503 for ; Tue, 11 Nov 2003 14:38:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeKx-0006YV-Hj for disman-archive@odin.ietf.org; Tue, 11 Nov 2003 14:38:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABJc3Ro025191 for disman-archive@odin.ietf.org; Tue, 11 Nov 2003 14:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeKw-0006YE-Lg for disman-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 14:38:02 -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 OAA17479 for ; Tue, 11 Nov 2003 14:37:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJeKt-0000or-00 for disman-web-archive@ietf.org; Tue, 11 Nov 2003 14:37:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJeKt-0000oo-00 for disman-web-archive@ietf.org; Tue, 11 Nov 2003 14:37:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeKv-0006XX-8l; Tue, 11 Nov 2003 14:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeKi-0006Tz-3s for disman@optimus.ietf.org; Tue, 11 Nov 2003 14:37:48 -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 OAA17453 for ; Tue, 11 Nov 2003 14:37:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJeKf-0000oX-00 for disman@ietf.org; Tue, 11 Nov 2003 14:37:45 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AJeKe-0000o6-00 for disman@ietf.org; Tue, 11 Nov 2003 14:37:44 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hABJbD122824 for ; Tue, 11 Nov 2003 14:37:13 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Nov 2003 14:37:13 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409390375@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] varbind offsets in alarm-mib-15 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 14:37:13 -0500 Hi The following is the proposed resolution to Randy-47. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 3.6, replace "The varbind reference approach taken in the Alarm MIB is that, for variables such as the alarmModelVarbindIndex, the first two obligatory varbinds of the InformRequest-PDU and SNMPv2-Trap-PDU are ignored, and the index aligns with the Trap-PDU and the SMI. In the case of linkDown, the first varbind would always be ifIndex." With "The varbind reference approach taken in the Alarm MIB is that, for variables such as the alarmModelVarbindIndex, the first two obligatory varbinds of the InformRequest-PDU and SNMPv2-Trap-PDU need to be considered so the index values of the Trap-PDU and the SMI need be adjusted by two. In the case of linkDown, the third varbind would always be ifIndex." In the description of alarmModelVarbindIndex replace " Note that the value of alarmModelVarbindIndex ignores the existence of the first two obligatory varbinds in the InformRequest-PDU and SNMPv2-Trap-PDU (sysUpTime.0 and snmpTrapOID.0). That is, a value of 1 refers to the first varbind after snmpTrapOID.0. If the incoming notification is instead an SNMPv1 Trap-PDU, then a value of 1 refers to the first varbind" With " Note that the value of alarmModelVarbindIndex acknowledges the existence of the first two obligatory varbinds in the InformRequest-PDU and SNMPv2-Trap-PDU (sysUpTime.0 and snmpTrapOID.0). That is, a value of 2 refers to the snmpTrapOID.0. If the incoming notification is instead an SNMPv1 Trap-PDU, then an appropriate value for sysUpTime.0 or snmpTrapOID.0 shall be determined by using the rules in section 3.1 of [RFC3584]" Also make any necessary changes to the examples in section 6. Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, October 22, 2003 8:40 AM To: Disman (E-mail) Subject: RE: [Disman] varbind offsets in alarm-mib-15 Hi I think it is somewhat dubious to consider working group consensus as the opinion of two people who reviewed the design long after working group last call, but if no one else objects I guess we can change the design. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 21, 2003 8:30 PM To: Disman (E-mail) Cc: Bert Wijnen Subject: Re: [Disman] varbind offsets in alarm-mib-15 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Saturday, October 18, 2003 10:57 AM > Subject: RE: [Disman] varbind offsets in alarm-mib-15 ... > Working group consensus was to translate from v1 traps to > Notifications, which is what we did for storage. I've just looked at > the discussion in the archive. I disagree (with your conclusion, not that you've looked at the archive :-) The consensus was to use the RFC 2576 approach to normalizing the payload into the SNMPv2 form. Which SMI was used to define the PDU that arrived is irrelevant, and may even be unknowable. The first varbind in the PDU should be number one. To assign any other number to the first varbind in the PDU would seem highly questionable, as it would seem highly questionable to claim that any other varbind should be called number one. > Subsequent discussion, and this is more from memory, talked about > designing alarm models and discussed the fact that people would be > designing them off the SMI, not the bits on the wire so it might be > confusing to include the sysUptime and trap OID in the numbering. I > remember Dave Partain saying something along the lines that he didn't > care which way it was done so long as it was properly explained in the > ID. I proposed the method in the current draft and I don't remember > any objections. ... Objections came from me and from Harrie Hazewinkel, whom I've quoted in previous discussions. This argument has been going on since Spring of 2002. I've seen no significant support for the position Sharon has advocated. As WG chair, I'm ruling that the consensus stands: the varbind lists should be handled v2-style, so that index value one refers to the first variable binding in the v2-formatted PDU. If the PDU came from some other protocol or mechanism, e.g., SNMPv1, then the RFC 2576 rules for mapping it into an SNMPv2-style PDU apply. If anyone thinks I have made this ruling in error, on either process or technical grounds, the applicable appeals process is described in RFC 2026 section 6.5.1. Randy Disman WG chair From disman-admin@ietf.org Tue Nov 11 14:44:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17699 for ; Tue, 11 Nov 2003 14:44:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeQi-00072s-Hx; Tue, 11 Nov 2003 14:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJePx-00072O-KB for disman@optimus.ietf.org; Tue, 11 Nov 2003 14:43:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17682 for ; Tue, 11 Nov 2003 14:43:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJePu-0000sx-00 for disman@ietf.org; Tue, 11 Nov 2003 14:43:10 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AJePu-0000so-00 for disman@ietf.org; Tue, 11 Nov 2003 14:43:10 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hABJgdY12149 for ; Tue, 11 Nov 2003 14:42:39 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Nov 2003 14:42:39 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409390387@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 14:42:36 -0500 Hi The following is the proposed resolution to Randy-65 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 4.1.1 replace " The relationship between the Alarm MIB and the other alarm model MIB modules is expressed by the following: The alarmModelTable has a corresponding table in the specific MIB. For each row in the specific MIB alarm model table there is one row in the alarmModelTable. The alarmActiveTable has a corresponding table in the specific MIBs. For each row in the specific MIB active alarm table, there is one row in the alarmActiveTable. The alarmModelSpecificPointer object in the alarmModelTable points to the specific model entry in an extended alarm model table corresponding to this particular alarm. The alarmActiveSpecificPointer object in the alarmActiveTable points to the specific active alarm entry in an extended active alarm table corresponding to this particular alarm instance. Additional extensions can be defined by defining an AUGEMENTATION of either the Alarm or ITU Alarm tables." With " The relationship between the Alarm MIB and the other alarm model MIB modules is expressed by the following: The alarmModelTable has a corresponding table in the specific MIB. For each row in the specific MIB alarm model table there is one row in the alarmModelTable. The alarmActiveTable has a corresponding table in the specific MIBs. For each row in the specific MIB active alarm table, there is one row in the alarmActiveTable. The alarmModelSpecificPointer object in the alarmModelTable points to the specific model entry in an extended alarm model table corresponding to this particular alarm. The alarmActiveSpecificPointer object in the alarmActiveTable points to the specific active alarm entry in an extended active alarm table corresponding to this particular alarm instance. In the case of the ITU Alarm MIB, for each row in the alarm model table there is one row in the ITU alarm model table. Additional extensions can be defined by defining an AUGEMENTATION of either the Alarm or ITU Alarm tables. As the alarm model table only provides a mechanism to point at one specific alarm model, additional specific models SHOULD define another mechanism to map from the generic alarm model to the additional model." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 22, 2003 3:06 AM To: Disman (E-mail) Subject: Re: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Hi - Though the final resolution of this will probably depend on 69-1, I do have a question / comment on this proposed change below. > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Saturday, October 18, 2003 3:32 PM > Subject: RE: [Disman] Section 5.1 in > draft-ietf-disman-alarm-mib-15.txt > > Hi > > The following is the proposed resolution to Randy-65 Assuming no > objection, this item will be considered closed conditional on the > proposed edit being done. > > In section 4.1.1 replace > > " The relationship between the Alarm MIB and the other alarm model MIB > modules is expressed by the following: The alarmModelTable has a > corresponding table in the specific MIB. For each row in the > specific MIB alarm model table there is one row in the > alarmModelTable. The alarmActiveTable has a corresponding table in > the specific MIBs. For each row in the specific MIB active alarm > table, there is one row in the alarmActiveTable. The > alarmModelSpecificPointer object in the alarmModelTable points to > the specific model entry in an extended alarm model table > corresponding to this particular alarm. The > alarmActiveSpecificPointer object in the alarmActiveTable points to > the specific active alarm entry in an extended active alarm table > corresponding to this particular alarm instance. > > Additional extensions can be defined by defining an AUGEMENTATION of > either the Alarm or ITU Alarm tables." > > With > > " The relationship between the Alarm MIB and the other alarm model MIB > modules is expressed by the following: The alarmModelTable has a > corresponding table in the specific MIB. For each row in the > specific MIB alarm model table there is one row in the > alarmModelTable. The alarmActiveTable has a corresponding table in > the specific MIBs. For each row in the specific MIB active alarm > table, there is one row in the alarmActiveTable. The > alarmModelSpecificPointer object in the alarmModelTable points to > the specific model entry in an extended alarm model table > corresponding to this particular alarm. The > alarmActiveSpecificPointer object in the alarmActiveTable points to > the specific active alarm entry in an extended active alarm table > corresponding to this particular alarm instance. > > In the case of the ITU Alarm MIB, for each row in the > alarm model table there is one row in the ITU alarm model table. If a system supports both the ITU alarm MIB and some other alarm extension MIB, then for a given entry in the alarmModelTable there will be: (a) an entry in the ITU alarm MIB, and no entry in the other extension MIB (b) an entry in both MIBs' tables I believe the proposed text preclude the third possibility (c) an entry in the other extension MIB, but not in the ITU alarm MIB. The upshot of this, I believe, is that only extension models corresponding to the ITU alarm model could be defined. I don't think that this was quite what we meant to do. > Additional extensions can be defined by defining an AUGEMENTATION of > either the Alarm or ITU Alarm tables. As the alarm model table only > provides a mechanism to point at one specific alarm model, > additional specific models SHOULD define another mechanism to map > from the generic alarm model to the additional model." ... I think that the the semantics of augmenting the Alarm table would be different from the semantics of augmenting the ITU alarm table, and that we shouldn't confuse the two cases. Randy From exim@www1.ietf.org Tue Nov 11 14:44:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17717 for ; Tue, 11 Nov 2003 14:44:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeQk-00074Q-BW for disman-archive@odin.ietf.org; Tue, 11 Nov 2003 14:44:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABJi22G027179 for disman-archive@odin.ietf.org; Tue, 11 Nov 2003 14:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeQk-000748-4n for disman-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 14:44:02 -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 OAA17695 for ; Tue, 11 Nov 2003 14:43:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJeQh-0000tJ-00 for disman-web-archive@ietf.org; Tue, 11 Nov 2003 14:43:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJeQg-0000tG-00 for disman-web-archive@ietf.org; Tue, 11 Nov 2003 14:43:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeQi-00072s-Hx; Tue, 11 Nov 2003 14:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJePx-00072O-KB for disman@optimus.ietf.org; Tue, 11 Nov 2003 14:43:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17682 for ; Tue, 11 Nov 2003 14:43:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJePu-0000sx-00 for disman@ietf.org; Tue, 11 Nov 2003 14:43:10 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AJePu-0000so-00 for disman@ietf.org; Tue, 11 Nov 2003 14:43:10 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hABJgdY12149 for ; Tue, 11 Nov 2003 14:42:39 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Nov 2003 14:42:39 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409390387@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 14:42:36 -0500 Hi The following is the proposed resolution to Randy-65 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 4.1.1 replace " The relationship between the Alarm MIB and the other alarm model MIB modules is expressed by the following: The alarmModelTable has a corresponding table in the specific MIB. For each row in the specific MIB alarm model table there is one row in the alarmModelTable. The alarmActiveTable has a corresponding table in the specific MIBs. For each row in the specific MIB active alarm table, there is one row in the alarmActiveTable. The alarmModelSpecificPointer object in the alarmModelTable points to the specific model entry in an extended alarm model table corresponding to this particular alarm. The alarmActiveSpecificPointer object in the alarmActiveTable points to the specific active alarm entry in an extended active alarm table corresponding to this particular alarm instance. Additional extensions can be defined by defining an AUGEMENTATION of either the Alarm or ITU Alarm tables." With " The relationship between the Alarm MIB and the other alarm model MIB modules is expressed by the following: The alarmModelTable has a corresponding table in the specific MIB. For each row in the specific MIB alarm model table there is one row in the alarmModelTable. The alarmActiveTable has a corresponding table in the specific MIBs. For each row in the specific MIB active alarm table, there is one row in the alarmActiveTable. The alarmModelSpecificPointer object in the alarmModelTable points to the specific model entry in an extended alarm model table corresponding to this particular alarm. The alarmActiveSpecificPointer object in the alarmActiveTable points to the specific active alarm entry in an extended active alarm table corresponding to this particular alarm instance. In the case of the ITU Alarm MIB, for each row in the alarm model table there is one row in the ITU alarm model table. Additional extensions can be defined by defining an AUGEMENTATION of either the Alarm or ITU Alarm tables. As the alarm model table only provides a mechanism to point at one specific alarm model, additional specific models SHOULD define another mechanism to map from the generic alarm model to the additional model." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 22, 2003 3:06 AM To: Disman (E-mail) Subject: Re: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Hi - Though the final resolution of this will probably depend on 69-1, I do have a question / comment on this proposed change below. > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Saturday, October 18, 2003 3:32 PM > Subject: RE: [Disman] Section 5.1 in > draft-ietf-disman-alarm-mib-15.txt > > Hi > > The following is the proposed resolution to Randy-65 Assuming no > objection, this item will be considered closed conditional on the > proposed edit being done. > > In section 4.1.1 replace > > " The relationship between the Alarm MIB and the other alarm model MIB > modules is expressed by the following: The alarmModelTable has a > corresponding table in the specific MIB. For each row in the > specific MIB alarm model table there is one row in the > alarmModelTable. The alarmActiveTable has a corresponding table in > the specific MIBs. For each row in the specific MIB active alarm > table, there is one row in the alarmActiveTable. The > alarmModelSpecificPointer object in the alarmModelTable points to > the specific model entry in an extended alarm model table > corresponding to this particular alarm. The > alarmActiveSpecificPointer object in the alarmActiveTable points to > the specific active alarm entry in an extended active alarm table > corresponding to this particular alarm instance. > > Additional extensions can be defined by defining an AUGEMENTATION of > either the Alarm or ITU Alarm tables." > > With > > " The relationship between the Alarm MIB and the other alarm model MIB > modules is expressed by the following: The alarmModelTable has a > corresponding table in the specific MIB. For each row in the > specific MIB alarm model table there is one row in the > alarmModelTable. The alarmActiveTable has a corresponding table in > the specific MIBs. For each row in the specific MIB active alarm > table, there is one row in the alarmActiveTable. The > alarmModelSpecificPointer object in the alarmModelTable points to > the specific model entry in an extended alarm model table > corresponding to this particular alarm. The > alarmActiveSpecificPointer object in the alarmActiveTable points to > the specific active alarm entry in an extended active alarm table > corresponding to this particular alarm instance. > > In the case of the ITU Alarm MIB, for each row in the > alarm model table there is one row in the ITU alarm model table. If a system supports both the ITU alarm MIB and some other alarm extension MIB, then for a given entry in the alarmModelTable there will be: (a) an entry in the ITU alarm MIB, and no entry in the other extension MIB (b) an entry in both MIBs' tables I believe the proposed text preclude the third possibility (c) an entry in the other extension MIB, but not in the ITU alarm MIB. The upshot of this, I believe, is that only extension models corresponding to the ITU alarm model could be defined. I don't think that this was quite what we meant to do. > Additional extensions can be defined by defining an AUGEMENTATION of > either the Alarm or ITU Alarm tables. As the alarm model table only > provides a mechanism to point at one specific alarm model, > additional specific models SHOULD define another mechanism to map > from the generic alarm model to the additional model." ... I think that the the semantics of augmenting the Alarm table would be different from the semantics of augmenting the ITU alarm table, and that we shouldn't confuse the two cases. Randy From disman-admin@ietf.org Wed Nov 12 10:18:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21602 for ; Wed, 12 Nov 2003 10:18:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwkr-0007CL-Aw; Wed, 12 Nov 2003 10:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwkP-0007BV-Rf for disman@optimus.ietf.org; Wed, 12 Nov 2003 10:17:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21483 for ; Wed, 12 Nov 2003 10:17:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJwkN-0000BZ-00 for disman@ietf.org; Wed, 12 Nov 2003 10:17:31 -0500 Received: from maynard.mail.mindspring.net ([207.69.200.243]) by ietf-mx with esmtp (Exim 4.12) id 1AJwkN-0000BW-00 for disman@ietf.org; Wed, 12 Nov 2003 10:17:31 -0500 Received: from [192.168.167.45] (helo=wamui07.slb.atl.earthlink.net) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AJwkM-00033x-00 for disman@ietf.org; Wed, 12 Nov 2003 10:17:30 -0500 Message-ID: <19943097.1068650250559.JavaMail.root@wamui07.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Subject: RE: [Disman] "table wrapping" in alarm MIB -15- Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 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: Wed, 12 Nov 2003 09:17:29 -0600 (GMT-06:00) Content-Transfer-Encoding: 7bit Hi - This looks ok to me. I'd suggest putting a UNITS on the proposed counter. Randy -----Original Message----- From: Sharon Chisholm Sent: Nov 11, 2003 12:23 PM To: "Disman (E-mail)" Subject: RE: [Disman] "table wrapping" in alarm MIB -15- Hi The following is the proposed resolution to Randy-75-4 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the definition of alarmActiveEntry replace "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared." With "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared. If under extreme resource constraint the system is unable to add any more entries into this table, then the alarmActiveOverflow statistic will be increased by one." Add new item alarmActiveOverflow OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of active alarms that have not been put into the alarmActiveTable since system restart as a result of extreme resource constraints." ::= { alarmActive 5 } Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 21, 2003 11:14 PM To: Disman (E-mail) Subject: Re: [Disman] "table wrapping" in alarm MIB -15- Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Tuesday, October 21, 2003 7:30 PM > Subject: RE: [Disman] "table wrapping" in alarm MIB -15- ... > I think we are in danger of fundamentally changing the architecture of > this 'active alarm' list for the sake of a corner case. It's not like > we didn't think of this, but rather that we didn't want an > architecture that encouraged partial active alarm lists. > > What exactly is the wg chair looking for with this? ... The chair wants the guy the AD asked to review the document to be happy. He'd like text that says what happens when an alarm model entry matches a notification delivered to the alarm inrastructure, and there is not sufficient storage (or other resources) available to create a new alarm entry. Possibilities: - no alarm entry is created - some alarm entry is deleted or cleared to make room (algorithm needs to be spelled out) - something records that this has happened My personal opinion is that creating no entry, and recording that fact in a counter is probably a reasonable solution, but am open to other possibilities. We went through the design issues in the log MIB. I suspect the tradeoffs are very similar here. This reviewer will be happy as long as the MIB is explicit about what happens; I think this MIB's proponents will figure out what the best thing would be to do when storage is exhausted. I agree that it's desirable to not encourage partial active alarm lists, but I also want *realistic* standards, i.e., no assumptions that storage is infinite. Randy (In all his roles. :-) From exim@www1.ietf.org Wed Nov 12 10:18:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21618 for ; Wed, 12 Nov 2003 10:18:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwkx-0007DG-9J for disman-archive@odin.ietf.org; Wed, 12 Nov 2003 10:18:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACFI7ti027722 for disman-archive@odin.ietf.org; Wed, 12 Nov 2003 10:18:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwkx-0007D3-62 for disman-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 10:18:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21533 for ; Wed, 12 Nov 2003 10:17:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJwku-0000C9-00 for disman-web-archive@ietf.org; Wed, 12 Nov 2003 10:18:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJwku-0000C2-00 for disman-web-archive@ietf.org; Wed, 12 Nov 2003 10:18:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwkr-0007CL-Aw; Wed, 12 Nov 2003 10:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwkP-0007BV-Rf for disman@optimus.ietf.org; Wed, 12 Nov 2003 10:17:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21483 for ; Wed, 12 Nov 2003 10:17:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJwkN-0000BZ-00 for disman@ietf.org; Wed, 12 Nov 2003 10:17:31 -0500 Received: from maynard.mail.mindspring.net ([207.69.200.243]) by ietf-mx with esmtp (Exim 4.12) id 1AJwkN-0000BW-00 for disman@ietf.org; Wed, 12 Nov 2003 10:17:31 -0500 Received: from [192.168.167.45] (helo=wamui07.slb.atl.earthlink.net) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AJwkM-00033x-00 for disman@ietf.org; Wed, 12 Nov 2003 10:17:30 -0500 Message-ID: <19943097.1068650250559.JavaMail.root@wamui07.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Subject: RE: [Disman] "table wrapping" in alarm MIB -15- Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 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: Wed, 12 Nov 2003 09:17:29 -0600 (GMT-06:00) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi - This looks ok to me. I'd suggest putting a UNITS on the proposed counter. Randy -----Original Message----- From: Sharon Chisholm Sent: Nov 11, 2003 12:23 PM To: "Disman (E-mail)" Subject: RE: [Disman] "table wrapping" in alarm MIB -15- Hi The following is the proposed resolution to Randy-75-4 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the definition of alarmActiveEntry replace "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared." With "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared. If under extreme resource constraint the system is unable to add any more entries into this table, then the alarmActiveOverflow statistic will be increased by one." Add new item alarmActiveOverflow OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of active alarms that have not been put into the alarmActiveTable since system restart as a result of extreme resource constraints." ::= { alarmActive 5 } Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 21, 2003 11:14 PM To: Disman (E-mail) Subject: Re: [Disman] "table wrapping" in alarm MIB -15- Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Tuesday, October 21, 2003 7:30 PM > Subject: RE: [Disman] "table wrapping" in alarm MIB -15- ... > I think we are in danger of fundamentally changing the architecture of > this 'active alarm' list for the sake of a corner case. It's not like > we didn't think of this, but rather that we didn't want an > architecture that encouraged partial active alarm lists. > > What exactly is the wg chair looking for with this? ... The chair wants the guy the AD asked to review the document to be happy. He'd like text that says what happens when an alarm model entry matches a notification delivered to the alarm inrastructure, and there is not sufficient storage (or other resources) available to create a new alarm entry. Possibilities: - no alarm entry is created - some alarm entry is deleted or cleared to make room (algorithm needs to be spelled out) - something records that this has happened My personal opinion is that creating no entry, and recording that fact in a counter is probably a reasonable solution, but am open to other possibilities. We went through the design issues in the log MIB. I suspect the tradeoffs are very similar here. This reviewer will be happy as long as the MIB is explicit about what happens; I think this MIB's proponents will figure out what the best thing would be to do when storage is exhausted. I agree that it's desirable to not encourage partial active alarm lists, but I also want *realistic* standards, i.e., no assumptions that storage is infinite. Randy (In all his roles. :-) From disman-admin@ietf.org Wed Nov 12 10:26:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21932 for ; Wed, 12 Nov 2003 10:26:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwse-0007bA-Op; Wed, 12 Nov 2003 10:26:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwsN-0007Yt-N5 for disman@optimus.ietf.org; Wed, 12 Nov 2003 10:25:49 -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 KAA21873 for ; Wed, 12 Nov 2003 10:25:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJwsL-0000HS-00 for disman@ietf.org; Wed, 12 Nov 2003 10:25:45 -0500 Received: from maynard.mail.mindspring.net ([207.69.200.243]) by ietf-mx with esmtp (Exim 4.12) id 1AJwsK-0000HO-00 for disman@ietf.org; Wed, 12 Nov 2003 10:25:44 -0500 Received: from [192.168.167.45] (helo=wamui07.slb.atl.earthlink.net) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AJwsJ-0000To-00 for disman@ietf.org; Wed, 12 Nov 2003 10:25:43 -0500 Message-ID: <6429790.1068650740596.JavaMail.root@wamui07.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Subject: RE: [Disman] Security considerations in draft-ietf-disman-alarm-m ib-15.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 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: Wed, 12 Nov 2003 09:25:37 -0600 (GMT-06:00) Content-Transfer-Encoding: 7bit Hi - Though I'd prefer to permit deletion of an alarm model (causing deletion of any corresponding alarms), this text would be ok with the original approach. A couple of typos: "multiple alarm" -> "multiple alarms" "uses the alarmActiveState" -> "use the alarmActiveState" "models when it has" -> "models when they have" Randy -----Original Message----- From: Sharon Chisholm Sent: Nov 11, 2003 12:44 PM To: "Disman (E-mail)" Subject: RE: [Disman] Security considerations in draft-ietf-disman-alarm-m ib-15.txt Hi The following is the proposed resolution to 75-2. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. Add the following text to the security considerations section. " Setting these objects may have disruptive effects on network operation by the flooding of unwanted alarm notifications from the network. It is possible to define multiple alarm that are triggered from the same frequently occurring internal stimulus and uses the alarmActiveState notification to inform interested managers. Since it is not possible to delete alarm models when it has active alarms, and the defined alarm throttling mechanism is limited to a single alarm, this could result in a continuous stream alarm notifications that there is no mechanism defined within this memo to control." Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, October 08, 2003 4:09 PM To: Disman (E-mail) Cc: Randy Presuhn Subject: RE: [Disman] Security considerations in draft-ietf-disman-alarm-m ib-15.txt Hi While I understand how the ARC MIB could be used to cause the problems that the IESG was concerned with, I don't really see where the Alarm MIB poses any more risk than 'normal' notifications. Ok. Let me put on my imagination hat: if a manager somehow sets up 323432 alarm models that alarm on the same internal stimulus and use the Alarm MIB notifications and then makes that internal stimulus happen, then 323432 notifications will get sent out on the wire. Is this what we are trying to warn people against? Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 3:58 PM To: Disman (E-mail) Subject: Re: [Disman] Security considerations in draft-ietf-disman-alarm-mib-15.txt Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 12:48 PM > Subject: RE: [Disman] Security considerations in > draft-ietf-disman-alarm-mib-15.txt .. > The following is the proposed resolution to Randy-75-2. Assuming no > objection, this item will is closed with no changes to the draft. I object, both as WG chair and as a technical contributor. > Assuming you referring to the following text: > > " Setting these objects may have disruptive effects on network > operation that range from omission of alarm notifications to > flooding of unwanted alarm notifications from the network. > The consequence of suppressing or deferring the reporting > of an alarm can prevent the timely delivery of important > diagnostic information, including information that can help > identify an attack." > > This is not relevant in the case of the Alarm MIB since we neither > suppress or defer notifications. We have text about throttling in the > 'normal' places within the draft. Technically: Even with the throttling language that's there, this MIB can be used to cause flooding, either due to an exessive number of resources going into alarm (throttling is in part per resource type), oscillating (throttling is on consecutive notifications), or distributed DoS (multiple systems configured). As Chair: Given the IESG's comments on the ARC MIB, which show that they are well aware of these issues, I believe we need to reconsider. Randy From exim@www1.ietf.org Wed Nov 12 10:26:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21948 for ; Wed, 12 Nov 2003 10:26:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwsl-0007cC-U1 for disman-archive@odin.ietf.org; Wed, 12 Nov 2003 10:26:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACFQB81029273 for disman-archive@odin.ietf.org; Wed, 12 Nov 2003 10:26:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwsk-0007c4-II for disman-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 10:26:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21902 for ; Wed, 12 Nov 2003 10:25:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJwsh-0000IN-00 for disman-web-archive@ietf.org; Wed, 12 Nov 2003 10:26:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJwsh-0000IK-00 for disman-web-archive@ietf.org; Wed, 12 Nov 2003 10:26:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwse-0007bA-Op; Wed, 12 Nov 2003 10:26:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwsN-0007Yt-N5 for disman@optimus.ietf.org; Wed, 12 Nov 2003 10:25:49 -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 KAA21873 for ; Wed, 12 Nov 2003 10:25:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJwsL-0000HS-00 for disman@ietf.org; Wed, 12 Nov 2003 10:25:45 -0500 Received: from maynard.mail.mindspring.net ([207.69.200.243]) by ietf-mx with esmtp (Exim 4.12) id 1AJwsK-0000HO-00 for disman@ietf.org; Wed, 12 Nov 2003 10:25:44 -0500 Received: from [192.168.167.45] (helo=wamui07.slb.atl.earthlink.net) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AJwsJ-0000To-00 for disman@ietf.org; Wed, 12 Nov 2003 10:25:43 -0500 Message-ID: <6429790.1068650740596.JavaMail.root@wamui07.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Subject: RE: [Disman] Security considerations in draft-ietf-disman-alarm-m ib-15.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 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: Wed, 12 Nov 2003 09:25:37 -0600 (GMT-06:00) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi - Though I'd prefer to permit deletion of an alarm model (causing deletion of any corresponding alarms), this text would be ok with the original approach. A couple of typos: "multiple alarm" -> "multiple alarms" "uses the alarmActiveState" -> "use the alarmActiveState" "models when it has" -> "models when they have" Randy -----Original Message----- From: Sharon Chisholm Sent: Nov 11, 2003 12:44 PM To: "Disman (E-mail)" Subject: RE: [Disman] Security considerations in draft-ietf-disman-alarm-m ib-15.txt Hi The following is the proposed resolution to 75-2. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. Add the following text to the security considerations section. " Setting these objects may have disruptive effects on network operation by the flooding of unwanted alarm notifications from the network. It is possible to define multiple alarm that are triggered from the same frequently occurring internal stimulus and uses the alarmActiveState notification to inform interested managers. Since it is not possible to delete alarm models when it has active alarms, and the defined alarm throttling mechanism is limited to a single alarm, this could result in a continuous stream alarm notifications that there is no mechanism defined within this memo to control." Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, October 08, 2003 4:09 PM To: Disman (E-mail) Cc: Randy Presuhn Subject: RE: [Disman] Security considerations in draft-ietf-disman-alarm-m ib-15.txt Hi While I understand how the ARC MIB could be used to cause the problems that the IESG was concerned with, I don't really see where the Alarm MIB poses any more risk than 'normal' notifications. Ok. Let me put on my imagination hat: if a manager somehow sets up 323432 alarm models that alarm on the same internal stimulus and use the Alarm MIB notifications and then makes that internal stimulus happen, then 323432 notifications will get sent out on the wire. Is this what we are trying to warn people against? Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 3:58 PM To: Disman (E-mail) Subject: Re: [Disman] Security considerations in draft-ietf-disman-alarm-mib-15.txt Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 12:48 PM > Subject: RE: [Disman] Security considerations in > draft-ietf-disman-alarm-mib-15.txt .. > The following is the proposed resolution to Randy-75-2. Assuming no > objection, this item will is closed with no changes to the draft. I object, both as WG chair and as a technical contributor. > Assuming you referring to the following text: > > " Setting these objects may have disruptive effects on network > operation that range from omission of alarm notifications to > flooding of unwanted alarm notifications from the network. > The consequence of suppressing or deferring the reporting > of an alarm can prevent the timely delivery of important > diagnostic information, including information that can help > identify an attack." > > This is not relevant in the case of the Alarm MIB since we neither > suppress or defer notifications. We have text about throttling in the > 'normal' places within the draft. Technically: Even with the throttling language that's there, this MIB can be used to cause flooding, either due to an exessive number of resources going into alarm (throttling is in part per resource type), oscillating (throttling is on consecutive notifications), or distributed DoS (multiple systems configured). As Chair: Given the IESG's comments on the ARC MIB, which show that they are well aware of these issues, I believe we need to reconsider. Randy From disman-admin@ietf.org Wed Nov 12 10:32:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22224 for ; Wed, 12 Nov 2003 10:32:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwyP-000826-Ri; Wed, 12 Nov 2003 10:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwxa-00081P-Kb for disman@optimus.ietf.org; Wed, 12 Nov 2003 10:31:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22195 for ; Wed, 12 Nov 2003 10:30:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJwxY-0000PN-00 for disman@ietf.org; Wed, 12 Nov 2003 10:31:08 -0500 Received: from maynard.mail.mindspring.net ([207.69.200.243]) by ietf-mx with esmtp (Exim 4.12) id 1AJwxX-0000PK-00 for disman@ietf.org; Wed, 12 Nov 2003 10:31:07 -0500 Received: from [192.168.167.45] (helo=wamui07.slb.atl.earthlink.net) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AJwxW-0005BR-00 for disman@ietf.org; Wed, 12 Nov 2003 10:31:06 -0500 Message-ID: <19390341.1068651065720.JavaMail.root@wamui07.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Subject: RE: [Disman] unthrottleable alarm state change notifications Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 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: Wed, 12 Nov 2003 09:31:05 -0600 (GMT-06:00) Content-Transfer-Encoding: 7bit Hi - This looks fine to me. However, it's not fully consistent with the proposed security considerations text, since permitting this deletion provides a way to stop runaway or oscillating configurations. I think the proposed text about it being possible to create runaways should remain, but this change provides a way to stop them. Randy -----Original Message----- From: Sharon Chisholm Sent: Nov 11, 2003 1:23 PM To: "Disman (E-mail)" Subject: RE: [Disman] unthrottleable alarm state change notifications Hi The following is the proposed resolution to Randy-55. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the description of alarmModelRowStatus replace " This row can not be modified or deleted while it is being referenced by a value of alarmActiveModelPointer. In these cases, an error of `inconsistentValue' will be returned to the manager." With " This row can not be modified while it is being referenced by a value of alarmActiveModelPointer. In these cases, an error of `inconsistentValue' will be returned to the manager. This entry may be deleted while it is being referenced by a value of alarmActiveModelPointer. This results in the deletion of this entry and entries in the active alarms referencing this entry via a alarmActiveModelPointer." Add the following text to the security considerations section "Changing values of alarmModelRowStatus as part of creating and deleting rows in the alarmModelTable result in adding new alarm models to the system or taking them out respectively. These operations need to be carefully planned. Adding a new model should be made in a consistent manner to avoid the system overflow with alarms. Taking out a model should result in the deletion of all this model related alarms in the system." Which I guess results in the following change to the text proposed to resolve Randy-75-2 Replace " Setting these objects may have disruptive effects on network operation by the flooding of unwanted alarm notifications from the network. It is possible to define multiple alarm that are triggered from the same frequently occurring internal stimulus and uses the alarmActiveState notification to inform interested managers. Since it is not possible to delete alarm models when it has active alarms, and the defined alarm throttling mechanism is limited to a single alarm, this could result in a continuous stream alarm notifications that there is no mechanism defined within this memo to control." With " Note that the alarm throttling mechanism associated with the alarmActiveState and alarmActiveClear notifications only applies to a given alarm. Defining multiple alarms from the same internal stimulus may then still result in a flood of alarms into the network." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 23, 2003 1:48 PM To: Disman (E-mail) Subject: Re: [Disman] unthrottleable alarm state change notifications Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > > Sent: Thursday, October 23, 2003 6:27 AM > Subject: RE: [Disman] unthrottleable alarm state change notifications ... > Yes. In general the text in the security considerations should be more > detailed in explaining the implications of performing write operations > on the read-write or read-create objects. For example in this case: > > 'Changes values of alarmModelRowStatus as part of creating and > deleting rows in the alarmModelTable result in adding new alarm models > to the system or taking them out. These operations need to be > carefully planned. Adding a new model should be made in a consistent > manner to avoid the system overflow with alarms. Taking out a model > should result in the deletion of all this model related alarms in the > system.' I like this a lot, though I think the last "should" should be a "MUST". I expect Sharon will wordsmith it into shape, if no one objects to it. Randy From exim@www1.ietf.org Wed Nov 12 10:32:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22239 for ; Wed, 12 Nov 2003 10:32:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwyR-00082y-MG for disman-archive@odin.ietf.org; Wed, 12 Nov 2003 10:32:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACFW35X030926 for disman-archive@odin.ietf.org; Wed, 12 Nov 2003 10:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwyR-00082j-Iw for disman-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 10:32:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22215 for ; Wed, 12 Nov 2003 10:31:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJwyO-0000Pd-00 for disman-web-archive@ietf.org; Wed, 12 Nov 2003 10:32:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJwyO-0000Pa-00 for disman-web-archive@ietf.org; Wed, 12 Nov 2003 10:32:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwyP-000826-Ri; Wed, 12 Nov 2003 10:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwxa-00081P-Kb for disman@optimus.ietf.org; Wed, 12 Nov 2003 10:31:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22195 for ; Wed, 12 Nov 2003 10:30:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJwxY-0000PN-00 for disman@ietf.org; Wed, 12 Nov 2003 10:31:08 -0500 Received: from maynard.mail.mindspring.net ([207.69.200.243]) by ietf-mx with esmtp (Exim 4.12) id 1AJwxX-0000PK-00 for disman@ietf.org; Wed, 12 Nov 2003 10:31:07 -0500 Received: from [192.168.167.45] (helo=wamui07.slb.atl.earthlink.net) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AJwxW-0005BR-00 for disman@ietf.org; Wed, 12 Nov 2003 10:31:06 -0500 Message-ID: <19390341.1068651065720.JavaMail.root@wamui07.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Subject: RE: [Disman] unthrottleable alarm state change notifications Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 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: Wed, 12 Nov 2003 09:31:05 -0600 (GMT-06:00) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi - This looks fine to me. However, it's not fully consistent with the proposed security considerations text, since permitting this deletion provides a way to stop runaway or oscillating configurations. I think the proposed text about it being possible to create runaways should remain, but this change provides a way to stop them. Randy -----Original Message----- From: Sharon Chisholm Sent: Nov 11, 2003 1:23 PM To: "Disman (E-mail)" Subject: RE: [Disman] unthrottleable alarm state change notifications Hi The following is the proposed resolution to Randy-55. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the description of alarmModelRowStatus replace " This row can not be modified or deleted while it is being referenced by a value of alarmActiveModelPointer. In these cases, an error of `inconsistentValue' will be returned to the manager." With " This row can not be modified while it is being referenced by a value of alarmActiveModelPointer. In these cases, an error of `inconsistentValue' will be returned to the manager. This entry may be deleted while it is being referenced by a value of alarmActiveModelPointer. This results in the deletion of this entry and entries in the active alarms referencing this entry via a alarmActiveModelPointer." Add the following text to the security considerations section "Changing values of alarmModelRowStatus as part of creating and deleting rows in the alarmModelTable result in adding new alarm models to the system or taking them out respectively. These operations need to be carefully planned. Adding a new model should be made in a consistent manner to avoid the system overflow with alarms. Taking out a model should result in the deletion of all this model related alarms in the system." Which I guess results in the following change to the text proposed to resolve Randy-75-2 Replace " Setting these objects may have disruptive effects on network operation by the flooding of unwanted alarm notifications from the network. It is possible to define multiple alarm that are triggered from the same frequently occurring internal stimulus and uses the alarmActiveState notification to inform interested managers. Since it is not possible to delete alarm models when it has active alarms, and the defined alarm throttling mechanism is limited to a single alarm, this could result in a continuous stream alarm notifications that there is no mechanism defined within this memo to control." With " Note that the alarm throttling mechanism associated with the alarmActiveState and alarmActiveClear notifications only applies to a given alarm. Defining multiple alarms from the same internal stimulus may then still result in a flood of alarms into the network." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 23, 2003 1:48 PM To: Disman (E-mail) Subject: Re: [Disman] unthrottleable alarm state change notifications Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > > Sent: Thursday, October 23, 2003 6:27 AM > Subject: RE: [Disman] unthrottleable alarm state change notifications ... > Yes. In general the text in the security considerations should be more > detailed in explaining the implications of performing write operations > on the read-write or read-create objects. For example in this case: > > 'Changes values of alarmModelRowStatus as part of creating and > deleting rows in the alarmModelTable result in adding new alarm models > to the system or taking them out. These operations need to be > carefully planned. Adding a new model should be made in a consistent > manner to avoid the system overflow with alarms. Taking out a model > should result in the deletion of all this model related alarms in the > system.' I like this a lot, though I think the last "should" should be a "MUST". I expect Sharon will wordsmith it into shape, if no one objects to it. Randy From disman-admin@ietf.org Wed Nov 12 10:36:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22499 for ; Wed, 12 Nov 2003 10:36:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJx2I-0008Ed-DK; Wed, 12 Nov 2003 10:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJx1u-0008Ax-TH for disman@optimus.ietf.org; Wed, 12 Nov 2003 10:35:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22453 for ; Wed, 12 Nov 2003 10:35:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJx1r-0000TB-00 for disman@ietf.org; Wed, 12 Nov 2003 10:35:35 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AJx1r-0000SM-00 for disman@ietf.org; Wed, 12 Nov 2003 10:35:35 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hACFZ2a04816 for ; Wed, 12 Nov 2003 10:35:02 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Nov 2003 10:35:03 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409390935@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Subject: RE: [Disman] unthrottleable alarm state change notifications 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, 12 Nov 2003 10:35:00 -0500 Hi The last item of this proposed change is to go back and replace the proposed text for Randy-75-2. I think it says what you indicate it should say. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, November 12, 2003 10:31 AM To: disman@ietf.org Subject: RE: [Disman] unthrottleable alarm state change notifications Hi - This looks fine to me. However, it's not fully consistent with the proposed security considerations text, since permitting this deletion provides a way to stop runaway or oscillating configurations. I think the proposed text about it being possible to create runaways should remain, but this change provides a way to stop them. Randy -----Original Message----- From: Sharon Chisholm Sent: Nov 11, 2003 1:23 PM To: "Disman (E-mail)" Subject: RE: [Disman] unthrottleable alarm state change notifications Hi The following is the proposed resolution to Randy-55. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the description of alarmModelRowStatus replace " This row can not be modified or deleted while it is being referenced by a value of alarmActiveModelPointer. In these cases, an error of `inconsistentValue' will be returned to the manager." With " This row can not be modified while it is being referenced by a value of alarmActiveModelPointer. In these cases, an error of `inconsistentValue' will be returned to the manager. This entry may be deleted while it is being referenced by a value of alarmActiveModelPointer. This results in the deletion of this entry and entries in the active alarms referencing this entry via a alarmActiveModelPointer." Add the following text to the security considerations section "Changing values of alarmModelRowStatus as part of creating and deleting rows in the alarmModelTable result in adding new alarm models to the system or taking them out respectively. These operations need to be carefully planned. Adding a new model should be made in a consistent manner to avoid the system overflow with alarms. Taking out a model should result in the deletion of all this model related alarms in the system." Which I guess results in the following change to the text proposed to resolve Randy-75-2 Replace " Setting these objects may have disruptive effects on network operation by the flooding of unwanted alarm notifications from the network. It is possible to define multiple alarm that are triggered from the same frequently occurring internal stimulus and uses the alarmActiveState notification to inform interested managers. Since it is not possible to delete alarm models when it has active alarms, and the defined alarm throttling mechanism is limited to a single alarm, this could result in a continuous stream alarm notifications that there is no mechanism defined within this memo to control." With " Note that the alarm throttling mechanism associated with the alarmActiveState and alarmActiveClear notifications only applies to a given alarm. Defining multiple alarms from the same internal stimulus may then still result in a flood of alarms into the network." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 23, 2003 1:48 PM To: Disman (E-mail) Subject: Re: [Disman] unthrottleable alarm state change notifications Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > > Sent: Thursday, October 23, 2003 6:27 AM > Subject: RE: [Disman] unthrottleable alarm state change notifications ... > Yes. In general the text in the security considerations should be more > detailed in explaining the implications of performing write operations > on the read-write or read-create objects. For example in this case: > > 'Changes values of alarmModelRowStatus as part of creating and > deleting rows in the alarmModelTable result in adding new alarm models > to the system or taking them out. These operations need to be > carefully planned. Adding a new model should be made in a consistent > manner to avoid the system overflow with alarms. Taking out a model > should result in the deletion of all this model related alarms in the > system.' I like this a lot, though I think the last "should" should be a "MUST". I expect Sharon will wordsmith it into shape, if no one objects to it. Randy From exim@www1.ietf.org Wed Nov 12 10:36:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22515 for ; Wed, 12 Nov 2003 10:36:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJx2L-0008G8-0F for disman-archive@odin.ietf.org; Wed, 12 Nov 2003 10:36:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACFa4Um031749 for disman-archive@odin.ietf.org; Wed, 12 Nov 2003 10:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJx2K-0008G0-Tc for disman-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 10:36:04 -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 KAA22473 for ; Wed, 12 Nov 2003 10:35:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJx2H-0000TZ-00 for disman-web-archive@ietf.org; Wed, 12 Nov 2003 10:36:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJx2H-0000TW-00 for disman-web-archive@ietf.org; Wed, 12 Nov 2003 10:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJx2I-0008Ed-DK; Wed, 12 Nov 2003 10:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJx1u-0008Ax-TH for disman@optimus.ietf.org; Wed, 12 Nov 2003 10:35:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22453 for ; Wed, 12 Nov 2003 10:35:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJx1r-0000TB-00 for disman@ietf.org; Wed, 12 Nov 2003 10:35:35 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AJx1r-0000SM-00 for disman@ietf.org; Wed, 12 Nov 2003 10:35:35 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hACFZ2a04816 for ; Wed, 12 Nov 2003 10:35:02 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Nov 2003 10:35:03 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409390935@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Subject: RE: [Disman] unthrottleable alarm state change notifications 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, 12 Nov 2003 10:35:00 -0500 Hi The last item of this proposed change is to go back and replace the proposed text for Randy-75-2. I think it says what you indicate it should say. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, November 12, 2003 10:31 AM To: disman@ietf.org Subject: RE: [Disman] unthrottleable alarm state change notifications Hi - This looks fine to me. However, it's not fully consistent with the proposed security considerations text, since permitting this deletion provides a way to stop runaway or oscillating configurations. I think the proposed text about it being possible to create runaways should remain, but this change provides a way to stop them. Randy -----Original Message----- From: Sharon Chisholm Sent: Nov 11, 2003 1:23 PM To: "Disman (E-mail)" Subject: RE: [Disman] unthrottleable alarm state change notifications Hi The following is the proposed resolution to Randy-55. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the description of alarmModelRowStatus replace " This row can not be modified or deleted while it is being referenced by a value of alarmActiveModelPointer. In these cases, an error of `inconsistentValue' will be returned to the manager." With " This row can not be modified while it is being referenced by a value of alarmActiveModelPointer. In these cases, an error of `inconsistentValue' will be returned to the manager. This entry may be deleted while it is being referenced by a value of alarmActiveModelPointer. This results in the deletion of this entry and entries in the active alarms referencing this entry via a alarmActiveModelPointer." Add the following text to the security considerations section "Changing values of alarmModelRowStatus as part of creating and deleting rows in the alarmModelTable result in adding new alarm models to the system or taking them out respectively. These operations need to be carefully planned. Adding a new model should be made in a consistent manner to avoid the system overflow with alarms. Taking out a model should result in the deletion of all this model related alarms in the system." Which I guess results in the following change to the text proposed to resolve Randy-75-2 Replace " Setting these objects may have disruptive effects on network operation by the flooding of unwanted alarm notifications from the network. It is possible to define multiple alarm that are triggered from the same frequently occurring internal stimulus and uses the alarmActiveState notification to inform interested managers. Since it is not possible to delete alarm models when it has active alarms, and the defined alarm throttling mechanism is limited to a single alarm, this could result in a continuous stream alarm notifications that there is no mechanism defined within this memo to control." With " Note that the alarm throttling mechanism associated with the alarmActiveState and alarmActiveClear notifications only applies to a given alarm. Defining multiple alarms from the same internal stimulus may then still result in a flood of alarms into the network." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 23, 2003 1:48 PM To: Disman (E-mail) Subject: Re: [Disman] unthrottleable alarm state change notifications Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > > Sent: Thursday, October 23, 2003 6:27 AM > Subject: RE: [Disman] unthrottleable alarm state change notifications ... > Yes. In general the text in the security considerations should be more > detailed in explaining the implications of performing write operations > on the read-write or read-create objects. For example in this case: > > 'Changes values of alarmModelRowStatus as part of creating and > deleting rows in the alarmModelTable result in adding new alarm models > to the system or taking them out. These operations need to be > carefully planned. Adding a new model should be made in a consistent > manner to avoid the system overflow with alarms. Taking out a model > should result in the deletion of all this model related alarms in the > system.' I like this a lot, though I think the last "should" should be a "MUST". I expect Sharon will wordsmith it into shape, if no one objects to it. Randy From disman-admin@ietf.org Wed Nov 12 10:41:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22743 for ; Wed, 12 Nov 2003 10:41:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJx76-0000Du-U0; Wed, 12 Nov 2003 10:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJx6d-0000DL-7y for disman@optimus.ietf.org; Wed, 12 Nov 2003 10:40: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 KAA22704 for ; Wed, 12 Nov 2003 10:40:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJx6a-0000Wb-00 for disman@ietf.org; Wed, 12 Nov 2003 10:40:28 -0500 Received: from maynard.mail.mindspring.net ([207.69.200.243]) by ietf-mx with esmtp (Exim 4.12) id 1AJx6Z-0000WX-00 for disman@ietf.org; Wed, 12 Nov 2003 10:40:27 -0500 Received: from [192.168.167.45] (helo=wamui07.slb.atl.earthlink.net) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AJx6U-0000R9-00 for disman@ietf.org; Wed, 12 Nov 2003 10:40:22 -0500 Message-ID: <25853782.1068651620227.JavaMail.root@wamui07.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 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: Wed, 12 Nov 2003 09:40:19 -0600 (GMT-06:00) Content-Transfer-Encoding: 7bit Hi - I think this is much clearer, though one sentence isn't always true: In the case of the ITU Alarm MIB, for each row in the alarm model table there is one row in the ITU alarm model table. This sentence is false for rows in the alarmModelTable where the value of the last index is greater than six. Randy -----Original Message----- From: Sharon Chisholm Sent: Nov 11, 2003 1:42 PM To: "Disman (E-mail)" Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Hi The following is the proposed resolution to Randy-65 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 4.1.1 replace " The relationship between the Alarm MIB and the other alarm model MIB modules is expressed by the following: The alarmModelTable has a corresponding table in the specific MIB. For each row in the specific MIB alarm model table there is one row in the alarmModelTable. The alarmActiveTable has a corresponding table in the specific MIBs. For each row in the specific MIB active alarm table, there is one row in the alarmActiveTable. The alarmModelSpecificPointer object in the alarmModelTable points to the specific model entry in an extended alarm model table corresponding to this particular alarm. The alarmActiveSpecificPointer object in the alarmActiveTable points to the specific active alarm entry in an extended active alarm table corresponding to this particular alarm instance. Additional extensions can be defined by defining an AUGEMENTATION of either the Alarm or ITU Alarm tables." With " The relationship between the Alarm MIB and the other alarm model MIB modules is expressed by the following: The alarmModelTable has a corresponding table in the specific MIB. For each row in the specific MIB alarm model table there is one row in the alarmModelTable. The alarmActiveTable has a corresponding table in the specific MIBs. For each row in the specific MIB active alarm table, there is one row in the alarmActiveTable. The alarmModelSpecificPointer object in the alarmModelTable points to the specific model entry in an extended alarm model table corresponding to this particular alarm. The alarmActiveSpecificPointer object in the alarmActiveTable points to the specific active alarm entry in an extended active alarm table corresponding to this particular alarm instance. In the case of the ITU Alarm MIB, for each row in the alarm model table there is one row in the ITU alarm model table. Additional extensions can be defined by defining an AUGEMENTATION of either the Alarm or ITU Alarm tables. As the alarm model table only provides a mechanism to point at one specific alarm model, additional specific models SHOULD define another mechanism to map from the generic alarm model to the additional model." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 22, 2003 3:06 AM To: Disman (E-mail) Subject: Re: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Hi - Though the final resolution of this will probably depend on 69-1, I do have a question / comment on this proposed change below. > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Saturday, October 18, 2003 3:32 PM > Subject: RE: [Disman] Section 5.1 in > draft-ietf-disman-alarm-mib-15.txt > > Hi > > The following is the proposed resolution to Randy-65 Assuming no > objection, this item will be considered closed conditional on the > proposed edit being done. > > In section 4.1.1 replace > > " The relationship between the Alarm MIB and the other alarm model MIB > modules is expressed by the following: The alarmModelTable has a > corresponding table in the specific MIB. For each row in the > specific MIB alarm model table there is one row in the > alarmModelTable. The alarmActiveTable has a corresponding table in > the specific MIBs. For each row in the specific MIB active alarm > table, there is one row in the alarmActiveTable. The > alarmModelSpecificPointer object in the alarmModelTable points to > the specific model entry in an extended alarm model table > corresponding to this particular alarm. The > alarmActiveSpecificPointer object in the alarmActiveTable points to > the specific active alarm entry in an extended active alarm table > corresponding to this particular alarm instance. > > Additional extensions can be defined by defining an AUGEMENTATION of > either the Alarm or ITU Alarm tables." > > With > > " The relationship between the Alarm MIB and the other alarm model MIB > modules is expressed by the following: The alarmModelTable has a > corresponding table in the specific MIB. For each row in the > specific MIB alarm model table there is one row in the > alarmModelTable. The alarmActiveTable has a corresponding table in > the specific MIBs. For each row in the specific MIB active alarm > table, there is one row in the alarmActiveTable. The > alarmModelSpecificPointer object in the alarmModelTable points to > the specific model entry in an extended alarm model table > corresponding to this particular alarm. The > alarmActiveSpecificPointer object in the alarmActiveTable points to > the specific active alarm entry in an extended active alarm table > corresponding to this particular alarm instance. > > In the case of the ITU Alarm MIB, for each row in the > alarm model table there is one row in the ITU alarm model table. If a system supports both the ITU alarm MIB and some other alarm extension MIB, then for a given entry in the alarmModelTable there will be: (a) an entry in the ITU alarm MIB, and no entry in the other extension MIB (b) an entry in both MIBs' tables I believe the proposed text preclude the third possibility (c) an entry in the other extension MIB, but not in the ITU alarm MIB. The upshot of this, I believe, is that only extension models corresponding to the ITU alarm model could be defined. I don't think that this was quite what we meant to do. > Additional extensions can be defined by defining an AUGEMENTATION of > either the Alarm or ITU Alarm tables. As the alarm model table only > provides a mechanism to point at one specific alarm model, > additional specific models SHOULD define another mechanism to map > from the generic alarm model to the additional model." ... I think that the the semantics of augmenting the Alarm table would be different from the semantics of augmenting the ITU alarm table, and that we shouldn't confuse the two cases. Randy From exim@www1.ietf.org Wed Nov 12 10:41:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22754 for ; Wed, 12 Nov 2003 10:41:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJx78-0000Ei-3j for disman-archive@odin.ietf.org; Wed, 12 Nov 2003 10:41:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACFf2uQ000902 for disman-archive@odin.ietf.org; Wed, 12 Nov 2003 10:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJx78-0000ET-0F for disman-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 10:41:02 -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 KAA22736 for ; Wed, 12 Nov 2003 10:40:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJx75-0000Wl-00 for disman-web-archive@ietf.org; Wed, 12 Nov 2003 10:40:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJx75-0000Wi-00 for disman-web-archive@ietf.org; Wed, 12 Nov 2003 10:40:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJx76-0000Du-U0; Wed, 12 Nov 2003 10:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJx6d-0000DL-7y for disman@optimus.ietf.org; Wed, 12 Nov 2003 10:40: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 KAA22704 for ; Wed, 12 Nov 2003 10:40:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJx6a-0000Wb-00 for disman@ietf.org; Wed, 12 Nov 2003 10:40:28 -0500 Received: from maynard.mail.mindspring.net ([207.69.200.243]) by ietf-mx with esmtp (Exim 4.12) id 1AJx6Z-0000WX-00 for disman@ietf.org; Wed, 12 Nov 2003 10:40:27 -0500 Received: from [192.168.167.45] (helo=wamui07.slb.atl.earthlink.net) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AJx6U-0000R9-00 for disman@ietf.org; Wed, 12 Nov 2003 10:40:22 -0500 Message-ID: <25853782.1068651620227.JavaMail.root@wamui07.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 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: Wed, 12 Nov 2003 09:40:19 -0600 (GMT-06:00) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi - I think this is much clearer, though one sentence isn't always true: In the case of the ITU Alarm MIB, for each row in the alarm model table there is one row in the ITU alarm model table. This sentence is false for rows in the alarmModelTable where the value of the last index is greater than six. Randy -----Original Message----- From: Sharon Chisholm Sent: Nov 11, 2003 1:42 PM To: "Disman (E-mail)" Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Hi The following is the proposed resolution to Randy-65 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 4.1.1 replace " The relationship between the Alarm MIB and the other alarm model MIB modules is expressed by the following: The alarmModelTable has a corresponding table in the specific MIB. For each row in the specific MIB alarm model table there is one row in the alarmModelTable. The alarmActiveTable has a corresponding table in the specific MIBs. For each row in the specific MIB active alarm table, there is one row in the alarmActiveTable. The alarmModelSpecificPointer object in the alarmModelTable points to the specific model entry in an extended alarm model table corresponding to this particular alarm. The alarmActiveSpecificPointer object in the alarmActiveTable points to the specific active alarm entry in an extended active alarm table corresponding to this particular alarm instance. Additional extensions can be defined by defining an AUGEMENTATION of either the Alarm or ITU Alarm tables." With " The relationship between the Alarm MIB and the other alarm model MIB modules is expressed by the following: The alarmModelTable has a corresponding table in the specific MIB. For each row in the specific MIB alarm model table there is one row in the alarmModelTable. The alarmActiveTable has a corresponding table in the specific MIBs. For each row in the specific MIB active alarm table, there is one row in the alarmActiveTable. The alarmModelSpecificPointer object in the alarmModelTable points to the specific model entry in an extended alarm model table corresponding to this particular alarm. The alarmActiveSpecificPointer object in the alarmActiveTable points to the specific active alarm entry in an extended active alarm table corresponding to this particular alarm instance. In the case of the ITU Alarm MIB, for each row in the alarm model table there is one row in the ITU alarm model table. Additional extensions can be defined by defining an AUGEMENTATION of either the Alarm or ITU Alarm tables. As the alarm model table only provides a mechanism to point at one specific alarm model, additional specific models SHOULD define another mechanism to map from the generic alarm model to the additional model." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 22, 2003 3:06 AM To: Disman (E-mail) Subject: Re: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Hi - Though the final resolution of this will probably depend on 69-1, I do have a question / comment on this proposed change below. > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Saturday, October 18, 2003 3:32 PM > Subject: RE: [Disman] Section 5.1 in > draft-ietf-disman-alarm-mib-15.txt > > Hi > > The following is the proposed resolution to Randy-65 Assuming no > objection, this item will be considered closed conditional on the > proposed edit being done. > > In section 4.1.1 replace > > " The relationship between the Alarm MIB and the other alarm model MIB > modules is expressed by the following: The alarmModelTable has a > corresponding table in the specific MIB. For each row in the > specific MIB alarm model table there is one row in the > alarmModelTable. The alarmActiveTable has a corresponding table in > the specific MIBs. For each row in the specific MIB active alarm > table, there is one row in the alarmActiveTable. The > alarmModelSpecificPointer object in the alarmModelTable points to > the specific model entry in an extended alarm model table > corresponding to this particular alarm. The > alarmActiveSpecificPointer object in the alarmActiveTable points to > the specific active alarm entry in an extended active alarm table > corresponding to this particular alarm instance. > > Additional extensions can be defined by defining an AUGEMENTATION of > either the Alarm or ITU Alarm tables." > > With > > " The relationship between the Alarm MIB and the other alarm model MIB > modules is expressed by the following: The alarmModelTable has a > corresponding table in the specific MIB. For each row in the > specific MIB alarm model table there is one row in the > alarmModelTable. The alarmActiveTable has a corresponding table in > the specific MIBs. For each row in the specific MIB active alarm > table, there is one row in the alarmActiveTable. The > alarmModelSpecificPointer object in the alarmModelTable points to > the specific model entry in an extended alarm model table > corresponding to this particular alarm. The > alarmActiveSpecificPointer object in the alarmActiveTable points to > the specific active alarm entry in an extended active alarm table > corresponding to this particular alarm instance. > > In the case of the ITU Alarm MIB, for each row in the > alarm model table there is one row in the ITU alarm model table. If a system supports both the ITU alarm MIB and some other alarm extension MIB, then for a given entry in the alarmModelTable there will be: (a) an entry in the ITU alarm MIB, and no entry in the other extension MIB (b) an entry in both MIBs' tables I believe the proposed text preclude the third possibility (c) an entry in the other extension MIB, but not in the ITU alarm MIB. The upshot of this, I believe, is that only extension models corresponding to the ITU alarm model could be defined. I don't think that this was quite what we meant to do. > Additional extensions can be defined by defining an AUGEMENTATION of > either the Alarm or ITU Alarm tables. As the alarm model table only > provides a mechanism to point at one specific alarm model, > additional specific models SHOULD define another mechanism to map > from the generic alarm model to the additional model." ... I think that the the semantics of augmenting the Alarm table would be different from the semantics of augmenting the ITU alarm table, and that we shouldn't confuse the two cases. Randy From disman-admin@ietf.org Wed Nov 12 10:45:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22982 for ; Wed, 12 Nov 2003 10:45:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxB1-0000Rv-2H; Wed, 12 Nov 2003 10:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxAK-0000QF-Kn for disman@optimus.ietf.org; Wed, 12 Nov 2003 10:44:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22925 for ; Wed, 12 Nov 2003 10:44:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxAI-0000as-00 for disman@ietf.org; Wed, 12 Nov 2003 10:44:18 -0500 Received: from maynard.mail.mindspring.net ([207.69.200.243]) by ietf-mx with esmtp (Exim 4.12) id 1AJxAH-0000ap-00 for disman@ietf.org; Wed, 12 Nov 2003 10:44:17 -0500 Received: from [192.168.167.45] (helo=wamui07.slb.atl.earthlink.net) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AJxAG-0005Bq-00 for disman@ietf.org; Wed, 12 Nov 2003 10:44:16 -0500 Message-ID: <9342770.1068651856680.JavaMail.root@wamui07.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Subject: RE: [Disman] unthrottleable alarm state change notifications Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 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: Wed, 12 Nov 2003 09:44:10 -0600 (GMT-06:00) Content-Transfer-Encoding: 7bit Hi - Ah. I missed that. Downside of trying to do email via a webpage. :-( I'm now happy with the proposed (combined) resolution of the items. (though it wouldn't hurt to mention in the security considerations that such a cascade can be stopped by deleting the offending alarm model.) Randy -----Original Message----- From: Sharon Chisholm Sent: Nov 12, 2003 9:35 AM To: disman@ietf.org Subject: RE: [Disman] unthrottleable alarm state change notifications Hi The last item of this proposed change is to go back and replace the proposed text for Randy-75-2. I think it says what you indicate it should say. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, November 12, 2003 10:31 AM To: disman@ietf.org Subject: RE: [Disman] unthrottleable alarm state change notifications Hi - This looks fine to me. However, it's not fully consistent with the proposed security considerations text, since permitting this deletion provides a way to stop runaway or oscillating configurations. I think the proposed text about it being possible to create runaways should remain, but this change provides a way to stop them. Randy -----Original Message----- From: Sharon Chisholm Sent: Nov 11, 2003 1:23 PM To: "Disman (E-mail)" Subject: RE: [Disman] unthrottleable alarm state change notifications Hi The following is the proposed resolution to Randy-55. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the description of alarmModelRowStatus replace " This row can not be modified or deleted while it is being referenced by a value of alarmActiveModelPointer. In these cases, an error of `inconsistentValue' will be returned to the manager." With " This row can not be modified while it is being referenced by a value of alarmActiveModelPointer. In these cases, an error of `inconsistentValue' will be returned to the manager. This entry may be deleted while it is being referenced by a value of alarmActiveModelPointer. This results in the deletion of this entry and entries in the active alarms referencing this entry via a alarmActiveModelPointer." Add the following text to the security considerations section "Changing values of alarmModelRowStatus as part of creating and deleting rows in the alarmModelTable result in adding new alarm models to the system or taking them out respectively. These operations need to be carefully planned. Adding a new model should be made in a consistent manner to avoid the system overflow with alarms. Taking out a model should result in the deletion of all this model related alarms in the system." Which I guess results in the following change to the text proposed to resolve Randy-75-2 Replace " Setting these objects may have disruptive effects on network operation by the flooding of unwanted alarm notifications from the network. It is possible to define multiple alarm that are triggered from the same frequently occurring internal stimulus and uses the alarmActiveState notification to inform interested managers. Since it is not possible to delete alarm models when it has active alarms, and the defined alarm throttling mechanism is limited to a single alarm, this could result in a continuous stream alarm notifications that there is no mechanism defined within this memo to control." With " Note that the alarm throttling mechanism associated with the alarmActiveState and alarmActiveClear notifications only applies to a given alarm. Defining multiple alarms from the same internal stimulus may then still result in a flood of alarms into the network." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 23, 2003 1:48 PM To: Disman (E-mail) Subject: Re: [Disman] unthrottleable alarm state change notifications Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > > Sent: Thursday, October 23, 2003 6:27 AM > Subject: RE: [Disman] unthrottleable alarm state change notifications ... > Yes. In general the text in the security considerations should be more > detailed in explaining the implications of performing write operations > on the read-write or read-create objects. For example in this case: > > 'Changes values of alarmModelRowStatus as part of creating and > deleting rows in the alarmModelTable result in adding new alarm models > to the system or taking them out. These operations need to be > carefully planned. Adding a new model should be made in a consistent > manner to avoid the system overflow with alarms. Taking out a model > should result in the deletion of all this model related alarms in the > system.' I like this a lot, though I think the last "should" should be a "MUST". I expect Sharon will wordsmith it into shape, if no one objects to it. Randy From exim@www1.ietf.org Wed Nov 12 10:45:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22996 for ; Wed, 12 Nov 2003 10:45:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxB2-0000Sj-B6 for disman-archive@odin.ietf.org; Wed, 12 Nov 2003 10:45:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACFj4Nf001771 for disman-archive@odin.ietf.org; Wed, 12 Nov 2003 10:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxB2-0000SU-7i for disman-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 10:45:04 -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 KAA22968 for ; Wed, 12 Nov 2003 10:44:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxAz-0000bu-00 for disman-web-archive@ietf.org; Wed, 12 Nov 2003 10:45:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJxAz-0000br-00 for disman-web-archive@ietf.org; Wed, 12 Nov 2003 10:45:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxB1-0000Rv-2H; Wed, 12 Nov 2003 10:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxAK-0000QF-Kn for disman@optimus.ietf.org; Wed, 12 Nov 2003 10:44:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22925 for ; Wed, 12 Nov 2003 10:44:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxAI-0000as-00 for disman@ietf.org; Wed, 12 Nov 2003 10:44:18 -0500 Received: from maynard.mail.mindspring.net ([207.69.200.243]) by ietf-mx with esmtp (Exim 4.12) id 1AJxAH-0000ap-00 for disman@ietf.org; Wed, 12 Nov 2003 10:44:17 -0500 Received: from [192.168.167.45] (helo=wamui07.slb.atl.earthlink.net) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AJxAG-0005Bq-00 for disman@ietf.org; Wed, 12 Nov 2003 10:44:16 -0500 Message-ID: <9342770.1068651856680.JavaMail.root@wamui07.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Subject: RE: [Disman] unthrottleable alarm state change notifications Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 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: Wed, 12 Nov 2003 09:44:10 -0600 (GMT-06:00) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi - Ah. I missed that. Downside of trying to do email via a webpage. :-( I'm now happy with the proposed (combined) resolution of the items. (though it wouldn't hurt to mention in the security considerations that such a cascade can be stopped by deleting the offending alarm model.) Randy -----Original Message----- From: Sharon Chisholm Sent: Nov 12, 2003 9:35 AM To: disman@ietf.org Subject: RE: [Disman] unthrottleable alarm state change notifications Hi The last item of this proposed change is to go back and replace the proposed text for Randy-75-2. I think it says what you indicate it should say. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, November 12, 2003 10:31 AM To: disman@ietf.org Subject: RE: [Disman] unthrottleable alarm state change notifications Hi - This looks fine to me. However, it's not fully consistent with the proposed security considerations text, since permitting this deletion provides a way to stop runaway or oscillating configurations. I think the proposed text about it being possible to create runaways should remain, but this change provides a way to stop them. Randy -----Original Message----- From: Sharon Chisholm Sent: Nov 11, 2003 1:23 PM To: "Disman (E-mail)" Subject: RE: [Disman] unthrottleable alarm state change notifications Hi The following is the proposed resolution to Randy-55. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the description of alarmModelRowStatus replace " This row can not be modified or deleted while it is being referenced by a value of alarmActiveModelPointer. In these cases, an error of `inconsistentValue' will be returned to the manager." With " This row can not be modified while it is being referenced by a value of alarmActiveModelPointer. In these cases, an error of `inconsistentValue' will be returned to the manager. This entry may be deleted while it is being referenced by a value of alarmActiveModelPointer. This results in the deletion of this entry and entries in the active alarms referencing this entry via a alarmActiveModelPointer." Add the following text to the security considerations section "Changing values of alarmModelRowStatus as part of creating and deleting rows in the alarmModelTable result in adding new alarm models to the system or taking them out respectively. These operations need to be carefully planned. Adding a new model should be made in a consistent manner to avoid the system overflow with alarms. Taking out a model should result in the deletion of all this model related alarms in the system." Which I guess results in the following change to the text proposed to resolve Randy-75-2 Replace " Setting these objects may have disruptive effects on network operation by the flooding of unwanted alarm notifications from the network. It is possible to define multiple alarm that are triggered from the same frequently occurring internal stimulus and uses the alarmActiveState notification to inform interested managers. Since it is not possible to delete alarm models when it has active alarms, and the defined alarm throttling mechanism is limited to a single alarm, this could result in a continuous stream alarm notifications that there is no mechanism defined within this memo to control." With " Note that the alarm throttling mechanism associated with the alarmActiveState and alarmActiveClear notifications only applies to a given alarm. Defining multiple alarms from the same internal stimulus may then still result in a flood of alarms into the network." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 23, 2003 1:48 PM To: Disman (E-mail) Subject: Re: [Disman] unthrottleable alarm state change notifications Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > > Sent: Thursday, October 23, 2003 6:27 AM > Subject: RE: [Disman] unthrottleable alarm state change notifications ... > Yes. In general the text in the security considerations should be more > detailed in explaining the implications of performing write operations > on the read-write or read-create objects. For example in this case: > > 'Changes values of alarmModelRowStatus as part of creating and > deleting rows in the alarmModelTable result in adding new alarm models > to the system or taking them out. These operations need to be > carefully planned. Adding a new model should be made in a consistent > manner to avoid the system overflow with alarms. Taking out a model > should result in the deletion of all this model related alarms in the > system.' I like this a lot, though I think the last "should" should be a "MUST". I expect Sharon will wordsmith it into shape, if no one objects to it. Randy From disman-admin@ietf.org Wed Nov 12 10:50:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23346 for ; Wed, 12 Nov 2003 10:50:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxFq-0000ir-M8; Wed, 12 Nov 2003 10:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxEx-0000hn-9E for disman@optimus.ietf.org; Wed, 12 Nov 2003 10:49:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23276 for ; Wed, 12 Nov 2003 10:48:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxEu-0000lW-00 for disman@ietf.org; Wed, 12 Nov 2003 10:49:04 -0500 Received: from maynard.mail.mindspring.net ([207.69.200.243]) by ietf-mx with esmtp (Exim 4.12) id 1AJxEu-0000lS-00 for disman@ietf.org; Wed, 12 Nov 2003 10:49:04 -0500 Received: from [192.168.167.45] (helo=wamui07.slb.atl.earthlink.net) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AJxEt-0000OS-00 for disman@ietf.org; Wed, 12 Nov 2003 10:49:03 -0500 Message-ID: <27690134.1068652143075.JavaMail.root@wamui07.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Subject: RE: [Disman] varbind offsets in alarm-mib-15 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 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: Wed, 12 Nov 2003 09:48:58 -0600 (GMT-06:00) Content-Transfer-Encoding: 7bit Hi - Looks ok to me. Thanks! Randy -----Original Message----- From: Sharon Chisholm Sent: Nov 11, 2003 1:37 PM To: "Disman (E-mail)" Subject: RE: [Disman] varbind offsets in alarm-mib-15 Hi The following is the proposed resolution to Randy-47. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 3.6, replace "The varbind reference approach taken in the Alarm MIB is that, for variables such as the alarmModelVarbindIndex, the first two obligatory varbinds of the InformRequest-PDU and SNMPv2-Trap-PDU are ignored, and the index aligns with the Trap-PDU and the SMI. In the case of linkDown, the first varbind would always be ifIndex." With "The varbind reference approach taken in the Alarm MIB is that, for variables such as the alarmModelVarbindIndex, the first two obligatory varbinds of the InformRequest-PDU and SNMPv2-Trap-PDU need to be considered so the index values of the Trap-PDU and the SMI need be adjusted by two. In the case of linkDown, the third varbind would always be ifIndex." In the description of alarmModelVarbindIndex replace " Note that the value of alarmModelVarbindIndex ignores the existence of the first two obligatory varbinds in the InformRequest-PDU and SNMPv2-Trap-PDU (sysUpTime.0 and snmpTrapOID.0). That is, a value of 1 refers to the first varbind after snmpTrapOID.0. If the incoming notification is instead an SNMPv1 Trap-PDU, then a value of 1 refers to the first varbind" With " Note that the value of alarmModelVarbindIndex acknowledges the existence of the first two obligatory varbinds in the InformRequest-PDU and SNMPv2-Trap-PDU (sysUpTime.0 and snmpTrapOID.0). That is, a value of 2 refers to the snmpTrapOID.0. If the incoming notification is instead an SNMPv1 Trap-PDU, then an appropriate value for sysUpTime.0 or snmpTrapOID.0 shall be determined by using the rules in section 3.1 of [RFC3584]" Also make any necessary changes to the examples in section 6. Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, October 22, 2003 8:40 AM To: Disman (E-mail) Subject: RE: [Disman] varbind offsets in alarm-mib-15 Hi I think it is somewhat dubious to consider working group consensus as the opinion of two people who reviewed the design long after working group last call, but if no one else objects I guess we can change the design. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 21, 2003 8:30 PM To: Disman (E-mail) Cc: Bert Wijnen Subject: Re: [Disman] varbind offsets in alarm-mib-15 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Saturday, October 18, 2003 10:57 AM > Subject: RE: [Disman] varbind offsets in alarm-mib-15 ... > Working group consensus was to translate from v1 traps to > Notifications, which is what we did for storage. I've just looked at > the discussion in the archive. I disagree (with your conclusion, not that you've looked at the archive :-) The consensus was to use the RFC 2576 approach to normalizing the payload into the SNMPv2 form. Which SMI was used to define the PDU that arrived is irrelevant, and may even be unknowable. The first varbind in the PDU should be number one. To assign any other number to the first varbind in the PDU would seem highly questionable, as it would seem highly questionable to claim that any other varbind should be called number one. > Subsequent discussion, and this is more from memory, talked about > designing alarm models and discussed the fact that people would be > designing them off the SMI, not the bits on the wire so it might be > confusing to include the sysUptime and trap OID in the numbering. I > remember Dave Partain saying something along the lines that he didn't > care which way it was done so long as it was properly explained in the > ID. I proposed the method in the current draft and I don't remember > any objections. ... Objections came from me and from Harrie Hazewinkel, whom I've quoted in previous discussions. This argument has been going on since Spring of 2002. I've seen no significant support for the position Sharon has advocated. As WG chair, I'm ruling that the consensus stands: the varbind lists should be handled v2-style, so that index value one refers to the first variable binding in the v2-formatted PDU. If the PDU came from some other protocol or mechanism, e.g., SNMPv1, then the RFC 2576 rules for mapping it into an SNMPv2-style PDU apply. If anyone thinks I have made this ruling in error, on either process or technical grounds, the applicable appeals process is described in RFC 2026 section 6.5.1. Randy Disman WG chair From exim@www1.ietf.org Wed Nov 12 10:50:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23367 for ; Wed, 12 Nov 2003 10:50:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxFt-0000kj-Eh for disman-archive@odin.ietf.org; Wed, 12 Nov 2003 10:50:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACFo5c0002887 for disman-archive@odin.ietf.org; Wed, 12 Nov 2003 10:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxFt-0000kU-8C for disman-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 10:50:05 -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 KAA23322 for ; Wed, 12 Nov 2003 10:49:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxFq-0000lv-00 for disman-web-archive@ietf.org; Wed, 12 Nov 2003 10:50:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJxFq-0000ls-00 for disman-web-archive@ietf.org; Wed, 12 Nov 2003 10:50:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxFq-0000ir-M8; Wed, 12 Nov 2003 10:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxEx-0000hn-9E for disman@optimus.ietf.org; Wed, 12 Nov 2003 10:49:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23276 for ; Wed, 12 Nov 2003 10:48:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxEu-0000lW-00 for disman@ietf.org; Wed, 12 Nov 2003 10:49:04 -0500 Received: from maynard.mail.mindspring.net ([207.69.200.243]) by ietf-mx with esmtp (Exim 4.12) id 1AJxEu-0000lS-00 for disman@ietf.org; Wed, 12 Nov 2003 10:49:04 -0500 Received: from [192.168.167.45] (helo=wamui07.slb.atl.earthlink.net) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AJxEt-0000OS-00 for disman@ietf.org; Wed, 12 Nov 2003 10:49:03 -0500 Message-ID: <27690134.1068652143075.JavaMail.root@wamui07.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Subject: RE: [Disman] varbind offsets in alarm-mib-15 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 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: Wed, 12 Nov 2003 09:48:58 -0600 (GMT-06:00) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi - Looks ok to me. Thanks! Randy -----Original Message----- From: Sharon Chisholm Sent: Nov 11, 2003 1:37 PM To: "Disman (E-mail)" Subject: RE: [Disman] varbind offsets in alarm-mib-15 Hi The following is the proposed resolution to Randy-47. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 3.6, replace "The varbind reference approach taken in the Alarm MIB is that, for variables such as the alarmModelVarbindIndex, the first two obligatory varbinds of the InformRequest-PDU and SNMPv2-Trap-PDU are ignored, and the index aligns with the Trap-PDU and the SMI. In the case of linkDown, the first varbind would always be ifIndex." With "The varbind reference approach taken in the Alarm MIB is that, for variables such as the alarmModelVarbindIndex, the first two obligatory varbinds of the InformRequest-PDU and SNMPv2-Trap-PDU need to be considered so the index values of the Trap-PDU and the SMI need be adjusted by two. In the case of linkDown, the third varbind would always be ifIndex." In the description of alarmModelVarbindIndex replace " Note that the value of alarmModelVarbindIndex ignores the existence of the first two obligatory varbinds in the InformRequest-PDU and SNMPv2-Trap-PDU (sysUpTime.0 and snmpTrapOID.0). That is, a value of 1 refers to the first varbind after snmpTrapOID.0. If the incoming notification is instead an SNMPv1 Trap-PDU, then a value of 1 refers to the first varbind" With " Note that the value of alarmModelVarbindIndex acknowledges the existence of the first two obligatory varbinds in the InformRequest-PDU and SNMPv2-Trap-PDU (sysUpTime.0 and snmpTrapOID.0). That is, a value of 2 refers to the snmpTrapOID.0. If the incoming notification is instead an SNMPv1 Trap-PDU, then an appropriate value for sysUpTime.0 or snmpTrapOID.0 shall be determined by using the rules in section 3.1 of [RFC3584]" Also make any necessary changes to the examples in section 6. Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, October 22, 2003 8:40 AM To: Disman (E-mail) Subject: RE: [Disman] varbind offsets in alarm-mib-15 Hi I think it is somewhat dubious to consider working group consensus as the opinion of two people who reviewed the design long after working group last call, but if no one else objects I guess we can change the design. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 21, 2003 8:30 PM To: Disman (E-mail) Cc: Bert Wijnen Subject: Re: [Disman] varbind offsets in alarm-mib-15 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Saturday, October 18, 2003 10:57 AM > Subject: RE: [Disman] varbind offsets in alarm-mib-15 ... > Working group consensus was to translate from v1 traps to > Notifications, which is what we did for storage. I've just looked at > the discussion in the archive. I disagree (with your conclusion, not that you've looked at the archive :-) The consensus was to use the RFC 2576 approach to normalizing the payload into the SNMPv2 form. Which SMI was used to define the PDU that arrived is irrelevant, and may even be unknowable. The first varbind in the PDU should be number one. To assign any other number to the first varbind in the PDU would seem highly questionable, as it would seem highly questionable to claim that any other varbind should be called number one. > Subsequent discussion, and this is more from memory, talked about > designing alarm models and discussed the fact that people would be > designing them off the SMI, not the bits on the wire so it might be > confusing to include the sysUptime and trap OID in the numbering. I > remember Dave Partain saying something along the lines that he didn't > care which way it was done so long as it was properly explained in the > ID. I proposed the method in the current draft and I don't remember > any objections. ... Objections came from me and from Harrie Hazewinkel, whom I've quoted in previous discussions. This argument has been going on since Spring of 2002. I've seen no significant support for the position Sharon has advocated. As WG chair, I'm ruling that the consensus stands: the varbind lists should be handled v2-style, so that index value one refers to the first variable binding in the v2-formatted PDU. If the PDU came from some other protocol or mechanism, e.g., SNMPv1, then the RFC 2576 rules for mapping it into an SNMPv2-style PDU apply. If anyone thinks I have made this ruling in error, on either process or technical grounds, the applicable appeals process is described in RFC 2026 section 6.5.1. Randy Disman WG chair From disman-admin@ietf.org Wed Nov 12 12:48:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29508 for ; Wed, 12 Nov 2003 12:48:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJz61-0003pm-C8; Wed, 12 Nov 2003 12:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJz5h-0003pW-Az for disman@optimus.ietf.org; Wed, 12 Nov 2003 12:47:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29489 for ; Wed, 12 Nov 2003 12:47:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJz5f-00033v-00 for disman@ietf.org; Wed, 12 Nov 2003 12:47:39 -0500 Received: from delicious.ietf58.ietf.org ([130.129.16.24]) by ietf-mx with esmtp (Exim 4.12) id 1AJz5e-00033s-00 for disman@ietf.org; Wed, 12 Nov 2003 12:47:38 -0500 Received: from dyn133-125.ietf58.ietf.org (dyn133-125.ietf58.ietf.org [130.129.133.125]) by delicious.ietf58.ietf.org (8.12.10/8.12.10) with ESMTP id hACHllKg002045 for ; Wed, 12 Nov 2003 11:47:48 -0600 (CST) From: Juergen Quittek To: disman@ietf.org Message-ID: <2147483647.1068662946@dyn133-125.ietf58.ietf.org> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Disman] REMOPS: any implementations? 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, 12 Nov 2003 18:49:06 +0100 Content-Transfer-Encoding: 7bit Dear all, We are considering to request to move RFC 2925 to draft standard. As one of the steps for doing so, I want to write an implementation report. If you have an implementation of the DISMAN-PING-MIB, the DISMAN-TRACEROUTE-MIB or the DISMAN-NSLOOKUP-MIB, or if you just know of one, please send me an email. Thanks, Juergen From exim@www1.ietf.org Wed Nov 12 12:48:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29520 for ; Wed, 12 Nov 2003 12:48:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJz66-0003qZ-1N for disman-archive@odin.ietf.org; Wed, 12 Nov 2003 12:48:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACHm6ml014781 for disman-archive@odin.ietf.org; Wed, 12 Nov 2003 12:48:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJz65-0003qK-TH for disman-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 12:48:05 -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 MAA29499 for ; Wed, 12 Nov 2003 12:47:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJz64-000348-00 for disman-web-archive@ietf.org; Wed, 12 Nov 2003 12:48:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJz63-000345-00 for disman-web-archive@ietf.org; Wed, 12 Nov 2003 12:48:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJz61-0003pm-C8; Wed, 12 Nov 2003 12:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJz5h-0003pW-Az for disman@optimus.ietf.org; Wed, 12 Nov 2003 12:47:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29489 for ; Wed, 12 Nov 2003 12:47:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJz5f-00033v-00 for disman@ietf.org; Wed, 12 Nov 2003 12:47:39 -0500 Received: from delicious.ietf58.ietf.org ([130.129.16.24]) by ietf-mx with esmtp (Exim 4.12) id 1AJz5e-00033s-00 for disman@ietf.org; Wed, 12 Nov 2003 12:47:38 -0500 Received: from dyn133-125.ietf58.ietf.org (dyn133-125.ietf58.ietf.org [130.129.133.125]) by delicious.ietf58.ietf.org (8.12.10/8.12.10) with ESMTP id hACHllKg002045 for ; Wed, 12 Nov 2003 11:47:48 -0600 (CST) From: Juergen Quittek To: disman@ietf.org Message-ID: <2147483647.1068662946@dyn133-125.ietf58.ietf.org> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Disman] REMOPS: any implementations? 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, 12 Nov 2003 18:49:06 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, We are considering to request to move RFC 2925 to draft standard. As one of the steps for doing so, I want to write an implementation report. If you have an implementation of the DISMAN-PING-MIB, the DISMAN-TRACEROUTE-MIB or the DISMAN-NSLOOKUP-MIB, or if you just know of one, please send me an email. Thanks, Juergen From disman-admin@ietf.org Wed Nov 12 23:40:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27236 for ; Wed, 12 Nov 2003 23:40:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK9H0-0004LE-7w; Wed, 12 Nov 2003 23:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK9GF-0004KD-2c for disman@optimus.ietf.org; Wed, 12 Nov 2003 23:39:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27189 for ; Wed, 12 Nov 2003 23:39:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK9GC-0005Rg-00 for disman@ietf.org; Wed, 12 Nov 2003 23:39:12 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AK9GB-0005Ra-00 for disman@ietf.org; Wed, 12 Nov 2003 23:39:12 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAD4ahJK016055 for ; Wed, 12 Nov 2003 23:36:43 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAD4agJK016045 for ; Wed, 12 Nov 2003 23:36:42 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOpM2tSulw24P1NQlO+0AgTEAOGrgAZG+ww From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , 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, 13 Nov 2003 06:39:05 +0200 Content-Transfer-Encoding: quoted-printable Correct, this sentence needs to be stroke out. Regards, Dan > -----Original Message----- > From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On=20 > Behalf Of Randy Presuhn > Sent: 12 November, 2003 5:40 PM > To: disman@ietf.org > Subject: RE: [Disman] Section 5.1 in=20 > draft-ietf-disman-alarm-mib-15.txt >=20 >=20 > Hi - >=20 > I think this is much clearer, though one sentence isn't always true: >=20 > In the case of the ITU Alarm MIB, for each row in the > alarm model table there is one row in the ITU alarm model table. >=20 > This sentence is false for rows in the alarmModelTable where the > value of the last index is greater than six. >=20 > Randy >=20 > -----Original Message----- > From: Sharon Chisholm > Sent: Nov 11, 2003 1:42 PM > To: "Disman (E-mail)" > Subject: RE: [Disman] Section 5.1 in=20 > draft-ietf-disman-alarm-mib-15.txt >=20 > Hi >=20 > The following is the proposed resolution to Randy-65 =20 > Assuming no objection, > this item will be considered closed conditional on the=20 > proposed edit being > done. >=20 > In section 4.1.1 replace >=20 > " The relationship between the Alarm MIB and the other alarm=20 > model MIB > modules is expressed by the following: The alarmModelTable has a > corresponding table in the specific MIB. For each row in the > specific MIB alarm model table there is one row in the > alarmModelTable. The alarmActiveTable has a corresponding table in > the specific MIBs. For each row in the specific MIB active alarm > table, there is one row in the alarmActiveTable. The > alarmModelSpecificPointer object in the alarmModelTable points to > the specific model entry in an extended alarm model table > corresponding to this particular alarm. The > alarmActiveSpecificPointer object in the alarmActiveTable points to > the specific active alarm entry in an extended active alarm table > corresponding to this particular alarm instance. >=20 > Additional extensions can be defined by defining an=20 > AUGEMENTATION of > either the Alarm or ITU Alarm tables." >=20 > With >=20 > " The relationship between the Alarm MIB and the other alarm=20 > model MIB > modules is expressed by the following: The alarmModelTable has a > corresponding table in the specific MIB. For each row in the > specific MIB alarm model table there is one row in the > alarmModelTable. The alarmActiveTable has a corresponding table in > the specific MIBs. For each row in the specific MIB active alarm > table, there is one row in the alarmActiveTable. The > alarmModelSpecificPointer object in the alarmModelTable points to > the specific model entry in an extended alarm model table > corresponding to this particular alarm. The > alarmActiveSpecificPointer object in the alarmActiveTable points to > the specific active alarm entry in an extended active alarm table > corresponding to this particular alarm instance. >=20 > In the case of the ITU Alarm MIB, for each row in the > alarm model table there is one row in the ITU alarm model table. >=20 > Additional extensions can be defined by defining an=20 > AUGEMENTATION of > either the Alarm or ITU Alarm tables. As the alarm model table only > provides a mechanism to point at one specific alarm model,=20 > additional specific models SHOULD define another mechanism to map > from the generic alarm model to the additional model." > =20 >=20 > Sharon >=20 >=20 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 > Sent: Wednesday, October 22, 2003 3:06 AM > To: Disman (E-mail) > Subject: Re: [Disman] Section 5.1 in=20 > draft-ietf-disman-alarm-mib-15.txt >=20 >=20 > Hi - >=20 > Though the final resolution of this will probably depend on=20 > 69-1, I do have > a question / comment on this proposed change below. >=20 > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Saturday, October 18, 2003 3:32 PM > > Subject: RE: [Disman] Section 5.1 in=20 > > draft-ietf-disman-alarm-mib-15.txt > > >=20 > > Hi > > > > The following is the proposed resolution to Randy-65 Assuming no=20 > > objection, this item will be considered closed conditional on the=20 > > proposed edit being done. > > > > In section 4.1.1 replace > > > > " The relationship between the Alarm MIB and the other=20 > alarm model MIB > > modules is expressed by the following: The alarmModelTable has a > > corresponding table in the specific MIB. For each row in the > > specific MIB alarm model table there is one row in the > > alarmModelTable. The alarmActiveTable has a=20 > corresponding table in > > the specific MIBs. For each row in the specific MIB active alarm > > table, there is one row in the alarmActiveTable. The > > alarmModelSpecificPointer object in the alarmModelTable points to > > the specific model entry in an extended alarm model table > > corresponding to this particular alarm. The > > alarmActiveSpecificPointer object in the=20 > alarmActiveTable points to > > the specific active alarm entry in an extended active alarm table > > corresponding to this particular alarm instance. > > > > Additional extensions can be defined by defining an=20 > AUGEMENTATION of > > either the Alarm or ITU Alarm tables." > > > > With > > > > " The relationship between the Alarm MIB and the other=20 > alarm model MIB > > modules is expressed by the following: The alarmModelTable has a > > corresponding table in the specific MIB. For each row in the > > specific MIB alarm model table there is one row in the > > alarmModelTable. The alarmActiveTable has a=20 > corresponding table in > > the specific MIBs. For each row in the specific MIB active alarm > > table, there is one row in the alarmActiveTable. The > > alarmModelSpecificPointer object in the alarmModelTable points to > > the specific model entry in an extended alarm model table > > corresponding to this particular alarm. The > > alarmActiveSpecificPointer object in the=20 > alarmActiveTable points to > > the specific active alarm entry in an extended active alarm table > > corresponding to this particular alarm instance. > > > > In the case of the ITU Alarm MIB, for each row in the > > alarm model table there is one row in the ITU alarm model table. >=20 > If a system supports both the ITU alarm MIB and some > other alarm extension MIB, then for a given entry in the=20 > alarmModelTable > there will be: > (a) an entry in the ITU alarm MIB, and no entry in the=20 > other extension > MIB > (b) an entry in both MIBs' tables >=20 > I believe the proposed text preclude the third possibility > (c) an entry in the other extension MIB, but not in the=20 > ITU alarm MIB. >=20 > The upshot of this, I believe, is that only extension models=20 > corresponding > to the ITU alarm model could be defined. I don't think that=20 > this was quite > what we meant to do. >=20 > > Additional extensions can be defined by defining an=20 > AUGEMENTATION of > > either the Alarm or ITU Alarm tables. As the alarm model=20 > table only > > provides a mechanism to point at one specific alarm model, > > additional specific models SHOULD define another mechanism to map > > from the generic alarm model to the additional model." > ... >=20 > I think that the the semantics of augmenting the Alarm table would be > different from the semantics of augmenting the ITU alarm=20 > table, and that we > shouldn't confuse the two cases. >=20 > Randy >=20 >=20 >=20 >=20 >=20 >=20 >=20 From exim@www1.ietf.org Wed Nov 12 23:40:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27250 for ; Wed, 12 Nov 2003 23:40:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK9H9-0004MC-Ji for disman-archive@odin.ietf.org; Wed, 12 Nov 2003 23:40:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD4eB5b016742 for disman-archive@odin.ietf.org; Wed, 12 Nov 2003 23:40:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK9H9-0004Lx-EX for disman-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 23:40:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27230 for ; Wed, 12 Nov 2003 23:39:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK9H7-0005SG-00 for disman-web-archive@ietf.org; Wed, 12 Nov 2003 23:40:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK9H6-0005SD-00 for disman-web-archive@ietf.org; Wed, 12 Nov 2003 23:40:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK9H0-0004LE-7w; Wed, 12 Nov 2003 23:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK9GF-0004KD-2c for disman@optimus.ietf.org; Wed, 12 Nov 2003 23:39:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27189 for ; Wed, 12 Nov 2003 23:39:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK9GC-0005Rg-00 for disman@ietf.org; Wed, 12 Nov 2003 23:39:12 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AK9GB-0005Ra-00 for disman@ietf.org; Wed, 12 Nov 2003 23:39:12 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAD4ahJK016055 for ; Wed, 12 Nov 2003 23:36:43 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAD4agJK016045 for ; Wed, 12 Nov 2003 23:36:42 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOpM2tSulw24P1NQlO+0AgTEAOGrgAZG+ww From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , 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, 13 Nov 2003 06:39:05 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Correct, this sentence needs to be stroke out. Regards, Dan > -----Original Message----- > From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On=20 > Behalf Of Randy Presuhn > Sent: 12 November, 2003 5:40 PM > To: disman@ietf.org > Subject: RE: [Disman] Section 5.1 in=20 > draft-ietf-disman-alarm-mib-15.txt >=20 >=20 > Hi - >=20 > I think this is much clearer, though one sentence isn't always true: >=20 > In the case of the ITU Alarm MIB, for each row in the > alarm model table there is one row in the ITU alarm model table. >=20 > This sentence is false for rows in the alarmModelTable where the > value of the last index is greater than six. >=20 > Randy >=20 > -----Original Message----- > From: Sharon Chisholm > Sent: Nov 11, 2003 1:42 PM > To: "Disman (E-mail)" > Subject: RE: [Disman] Section 5.1 in=20 > draft-ietf-disman-alarm-mib-15.txt >=20 > Hi >=20 > The following is the proposed resolution to Randy-65 =20 > Assuming no objection, > this item will be considered closed conditional on the=20 > proposed edit being > done. >=20 > In section 4.1.1 replace >=20 > " The relationship between the Alarm MIB and the other alarm=20 > model MIB > modules is expressed by the following: The alarmModelTable has a > corresponding table in the specific MIB. For each row in the > specific MIB alarm model table there is one row in the > alarmModelTable. The alarmActiveTable has a corresponding table in > the specific MIBs. For each row in the specific MIB active alarm > table, there is one row in the alarmActiveTable. The > alarmModelSpecificPointer object in the alarmModelTable points to > the specific model entry in an extended alarm model table > corresponding to this particular alarm. The > alarmActiveSpecificPointer object in the alarmActiveTable points to > the specific active alarm entry in an extended active alarm table > corresponding to this particular alarm instance. >=20 > Additional extensions can be defined by defining an=20 > AUGEMENTATION of > either the Alarm or ITU Alarm tables." >=20 > With >=20 > " The relationship between the Alarm MIB and the other alarm=20 > model MIB > modules is expressed by the following: The alarmModelTable has a > corresponding table in the specific MIB. For each row in the > specific MIB alarm model table there is one row in the > alarmModelTable. The alarmActiveTable has a corresponding table in > the specific MIBs. For each row in the specific MIB active alarm > table, there is one row in the alarmActiveTable. The > alarmModelSpecificPointer object in the alarmModelTable points to > the specific model entry in an extended alarm model table > corresponding to this particular alarm. The > alarmActiveSpecificPointer object in the alarmActiveTable points to > the specific active alarm entry in an extended active alarm table > corresponding to this particular alarm instance. >=20 > In the case of the ITU Alarm MIB, for each row in the > alarm model table there is one row in the ITU alarm model table. >=20 > Additional extensions can be defined by defining an=20 > AUGEMENTATION of > either the Alarm or ITU Alarm tables. As the alarm model table only > provides a mechanism to point at one specific alarm model,=20 > additional specific models SHOULD define another mechanism to map > from the generic alarm model to the additional model." > =20 >=20 > Sharon >=20 >=20 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 > Sent: Wednesday, October 22, 2003 3:06 AM > To: Disman (E-mail) > Subject: Re: [Disman] Section 5.1 in=20 > draft-ietf-disman-alarm-mib-15.txt >=20 >=20 > Hi - >=20 > Though the final resolution of this will probably depend on=20 > 69-1, I do have > a question / comment on this proposed change below. >=20 > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Saturday, October 18, 2003 3:32 PM > > Subject: RE: [Disman] Section 5.1 in=20 > > draft-ietf-disman-alarm-mib-15.txt > > >=20 > > Hi > > > > The following is the proposed resolution to Randy-65 Assuming no=20 > > objection, this item will be considered closed conditional on the=20 > > proposed edit being done. > > > > In section 4.1.1 replace > > > > " The relationship between the Alarm MIB and the other=20 > alarm model MIB > > modules is expressed by the following: The alarmModelTable has a > > corresponding table in the specific MIB. For each row in the > > specific MIB alarm model table there is one row in the > > alarmModelTable. The alarmActiveTable has a=20 > corresponding table in > > the specific MIBs. For each row in the specific MIB active alarm > > table, there is one row in the alarmActiveTable. The > > alarmModelSpecificPointer object in the alarmModelTable points to > > the specific model entry in an extended alarm model table > > corresponding to this particular alarm. The > > alarmActiveSpecificPointer object in the=20 > alarmActiveTable points to > > the specific active alarm entry in an extended active alarm table > > corresponding to this particular alarm instance. > > > > Additional extensions can be defined by defining an=20 > AUGEMENTATION of > > either the Alarm or ITU Alarm tables." > > > > With > > > > " The relationship between the Alarm MIB and the other=20 > alarm model MIB > > modules is expressed by the following: The alarmModelTable has a > > corresponding table in the specific MIB. For each row in the > > specific MIB alarm model table there is one row in the > > alarmModelTable. The alarmActiveTable has a=20 > corresponding table in > > the specific MIBs. For each row in the specific MIB active alarm > > table, there is one row in the alarmActiveTable. The > > alarmModelSpecificPointer object in the alarmModelTable points to > > the specific model entry in an extended alarm model table > > corresponding to this particular alarm. The > > alarmActiveSpecificPointer object in the=20 > alarmActiveTable points to > > the specific active alarm entry in an extended active alarm table > > corresponding to this particular alarm instance. > > > > In the case of the ITU Alarm MIB, for each row in the > > alarm model table there is one row in the ITU alarm model table. >=20 > If a system supports both the ITU alarm MIB and some > other alarm extension MIB, then for a given entry in the=20 > alarmModelTable > there will be: > (a) an entry in the ITU alarm MIB, and no entry in the=20 > other extension > MIB > (b) an entry in both MIBs' tables >=20 > I believe the proposed text preclude the third possibility > (c) an entry in the other extension MIB, but not in the=20 > ITU alarm MIB. >=20 > The upshot of this, I believe, is that only extension models=20 > corresponding > to the ITU alarm model could be defined. I don't think that=20 > this was quite > what we meant to do. >=20 > > Additional extensions can be defined by defining an=20 > AUGEMENTATION of > > either the Alarm or ITU Alarm tables. As the alarm model=20 > table only > > provides a mechanism to point at one specific alarm model, > > additional specific models SHOULD define another mechanism to map > > from the generic alarm model to the additional model." > ... >=20 > I think that the the semantics of augmenting the Alarm table would be > different from the semantics of augmenting the ITU alarm=20 > table, and that we > shouldn't confuse the two cases. >=20 > Randy >=20 >=20 >=20 >=20 >=20 >=20 >=20 From disman-admin@ietf.org Mon Nov 17 08:58:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11841 for ; Mon, 17 Nov 2003 08:58:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjtB-0007sz-41; Mon, 17 Nov 2003 08:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjsT-0007sS-EZ for disman@optimus.ietf.org; Mon, 17 Nov 2003 08:57:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11800 for ; Mon, 17 Nov 2003 08:57:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALjsR-0006pm-00 for disman@ietf.org; Mon, 17 Nov 2003 08:57:15 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ALjsR-0006p2-00 for disman@ietf.org; Mon, 17 Nov 2003 08:57:15 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAHDugh01824 for ; Mon, 17 Nov 2003 08:56:42 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Nov 2003 08:56:42 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409464155@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Closed item from Randy's Review 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: Mon, 17 Nov 2003 08:56:41 -0500 Hi Current Score: The following items are closed: 1-10, 13, 15-23, 25, 27, 29-34, 36-38, 40-41, 45-46, 48, 50-54, 57, 60-61, 64, 67, 69-2, 70, 72-73, 74, 75-3 The following items are conditionally closed: 11, 12, 14, 17, 24, 26, 28, 35, 39, 42-44, 47, 49, 55-56, 58-59, 62-63, 65-66, 68, 71, 75-1,75-2, N+1,N+2, N+3 The following items are still be processed: 65, 69-1, 75-4 Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Sunday, November 02, 2003 5:29 AM To: Disman (E-mail) Subject: RE: [Disman] Closed item from Randy's Review Hi Current Score: The following items are closed: 1-10, 13, 15-23, 25, 27, 29-34, 36-38, 40-41, 45-46, 48, 50-54, 57, 60-61, 64, 67, 69-2, 70, 72-73, 74, 75-3 The following items are conditionally closed: 11, 12, 14, 17, 24, 28, 35, 42-44, 49, 56, 58, 62-63, 65-66, 71, 75-1, N+1,N+2, N+3 The following items are still be processed: 26, 39, 47, 55, 59, 65, 68, 69-1, 75-2, 75-4 Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, October 15, 2003 12:37 PM To: Disman (E-mail) Subject: RE: [Disman] Closed item from Randy's Review Hi For those keeping score at home, this is where we stand: The following items are closed: 1-10, 13, 15-23, 25, 27, 29-34, 36-38, 40-41, 45-46, 48, 50-54, 57, 61, 64, 67, 69-2, 70, 72-73, 74, 75-3 The following items are conditionally closed: 11, 12, 14, 17, 35, 42-43, 49, 62-63, 65-66, 71, N+1 The following items are still be processed: 24, 26, 28, 39, 44, 47, 55-56, 58-60, 65, 68, 69-1, 75-1. 75-2, 75-4, N+2, N+3 Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Tuesday, October 07, 2003 1:46 PM To: Disman (E-mail) Cc: Randy Presuhn Subject: RE: [Disman] Closed item from Randy's Review Hi As I said, the email was to ensure we were all on the same page. It is not in anybody's best interest for a -16 to be created and then have these issues brought up again. When can we expect a thumbs up/down on the remaining items? Any items not in this list will be handled separately. I want the remaining items conditionally closed before issuing -16. As in, if text X is replaced with text Y then this issue is closed. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 07, 2003 1:32 PM To: Disman (E-mail) Subject: Re: [Disman] Closed item from Randy's Review Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Tuesday, October 07, 2003 9:40 AM > Subject: [Disman] Closed item from Randy's Review ... > Just to ensure we are on the same page: Having received no indication > that the update -15 or the explanation for not making an update did > not satisfy the issue, the follow issues are considered closed: > > 1, 3-10, 13, 15-25, 27-32, 34, 36-41, 45-46, 48, 50-54, 56-57, 60-61, > 64, 67-69, 73, 74-1, 74-2, 74-4, 75-1 ... Not so fast. Numbers 24, 28, 39, 56, 60, 75-1, 68, and 69-1 I still need to check, so I object to considering them closed until I've had an opportunity to do so. I assume this means you agree to fix #17. I strongly RECOMMEND fixing 7, 13, 15a, and 16. Randy (as technical contributor) From exim@www1.ietf.org Mon Nov 17 08:58:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11856 for ; Mon, 17 Nov 2003 08:58:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjtH-0007tq-ES for disman-archive@odin.ietf.org; Mon, 17 Nov 2003 08:58:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHDw7Sa030360 for disman-archive@odin.ietf.org; Mon, 17 Nov 2003 08:58:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjtH-0007tb-Ar for disman-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 08:58:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11819 for ; Mon, 17 Nov 2003 08:57:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALjtF-0006qH-00 for disman-web-archive@ietf.org; Mon, 17 Nov 2003 08:58:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALjtF-0006qD-00 for disman-web-archive@ietf.org; Mon, 17 Nov 2003 08:58:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjtB-0007sz-41; Mon, 17 Nov 2003 08:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjsT-0007sS-EZ for disman@optimus.ietf.org; Mon, 17 Nov 2003 08:57:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11800 for ; Mon, 17 Nov 2003 08:57:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALjsR-0006pm-00 for disman@ietf.org; Mon, 17 Nov 2003 08:57:15 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ALjsR-0006p2-00 for disman@ietf.org; Mon, 17 Nov 2003 08:57:15 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAHDugh01824 for ; Mon, 17 Nov 2003 08:56:42 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Nov 2003 08:56:42 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409464155@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Closed item from Randy's Review 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: Mon, 17 Nov 2003 08:56:41 -0500 Hi Current Score: The following items are closed: 1-10, 13, 15-23, 25, 27, 29-34, 36-38, 40-41, 45-46, 48, 50-54, 57, 60-61, 64, 67, 69-2, 70, 72-73, 74, 75-3 The following items are conditionally closed: 11, 12, 14, 17, 24, 26, 28, 35, 39, 42-44, 47, 49, 55-56, 58-59, 62-63, 65-66, 68, 71, 75-1,75-2, N+1,N+2, N+3 The following items are still be processed: 65, 69-1, 75-4 Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Sunday, November 02, 2003 5:29 AM To: Disman (E-mail) Subject: RE: [Disman] Closed item from Randy's Review Hi Current Score: The following items are closed: 1-10, 13, 15-23, 25, 27, 29-34, 36-38, 40-41, 45-46, 48, 50-54, 57, 60-61, 64, 67, 69-2, 70, 72-73, 74, 75-3 The following items are conditionally closed: 11, 12, 14, 17, 24, 28, 35, 42-44, 49, 56, 58, 62-63, 65-66, 71, 75-1, N+1,N+2, N+3 The following items are still be processed: 26, 39, 47, 55, 59, 65, 68, 69-1, 75-2, 75-4 Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, October 15, 2003 12:37 PM To: Disman (E-mail) Subject: RE: [Disman] Closed item from Randy's Review Hi For those keeping score at home, this is where we stand: The following items are closed: 1-10, 13, 15-23, 25, 27, 29-34, 36-38, 40-41, 45-46, 48, 50-54, 57, 61, 64, 67, 69-2, 70, 72-73, 74, 75-3 The following items are conditionally closed: 11, 12, 14, 17, 35, 42-43, 49, 62-63, 65-66, 71, N+1 The following items are still be processed: 24, 26, 28, 39, 44, 47, 55-56, 58-60, 65, 68, 69-1, 75-1. 75-2, 75-4, N+2, N+3 Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Tuesday, October 07, 2003 1:46 PM To: Disman (E-mail) Cc: Randy Presuhn Subject: RE: [Disman] Closed item from Randy's Review Hi As I said, the email was to ensure we were all on the same page. It is not in anybody's best interest for a -16 to be created and then have these issues brought up again. When can we expect a thumbs up/down on the remaining items? Any items not in this list will be handled separately. I want the remaining items conditionally closed before issuing -16. As in, if text X is replaced with text Y then this issue is closed. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 07, 2003 1:32 PM To: Disman (E-mail) Subject: Re: [Disman] Closed item from Randy's Review Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Tuesday, October 07, 2003 9:40 AM > Subject: [Disman] Closed item from Randy's Review ... > Just to ensure we are on the same page: Having received no indication > that the update -15 or the explanation for not making an update did > not satisfy the issue, the follow issues are considered closed: > > 1, 3-10, 13, 15-25, 27-32, 34, 36-41, 45-46, 48, 50-54, 56-57, 60-61, > 64, 67-69, 73, 74-1, 74-2, 74-4, 75-1 ... Not so fast. Numbers 24, 28, 39, 56, 60, 75-1, 68, and 69-1 I still need to check, so I object to considering them closed until I've had an opportunity to do so. I assume this means you agree to fix #17. I strongly RECOMMEND fixing 7, 13, 15a, and 16. Randy (as technical contributor) From disman-admin@ietf.org Mon Nov 17 09:00:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11932 for ; Mon, 17 Nov 2003 09:00:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjv9-0007xZ-0I; Mon, 17 Nov 2003 09:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjuW-0007wf-Ch for disman@optimus.ietf.org; Mon, 17 Nov 2003 08:59:24 -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 IAA11890 for ; Mon, 17 Nov 2003 08:59:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALjuU-0006r1-00 for disman@ietf.org; Mon, 17 Nov 2003 08:59:23 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ALjuU-0006qb-00 for disman@ietf.org; Mon, 17 Nov 2003 08:59:22 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAHDwo302504 for ; Mon, 17 Nov 2003 08:58:50 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Nov 2003 08:58:50 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340946415F@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt 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: Mon, 17 Nov 2003 08:58:43 -0500 Hi The following is the proposed resolution to Randy-65 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 4.1.1 replace " The relationship between the Alarm MIB and the other alarm model MIB modules is expressed by the following: The alarmModelTable has a corresponding table in the specific MIB. For each row in the specific MIB alarm model table there is one row in the alarmModelTable. The alarmActiveTable has a corresponding table in the specific MIBs. For each row in the specific MIB active alarm table, there is one row in the alarmActiveTable. The alarmModelSpecificPointer object in the alarmModelTable points to the specific model entry in an extended alarm model table corresponding to this particular alarm. The alarmActiveSpecificPointer object in the alarmActiveTable points to the specific active alarm entry in an extended active alarm table corresponding to this particular alarm instance. Additional extensions can be defined by defining an AUGEMENTATION of either the Alarm or ITU Alarm tables." With " The relationship between the Alarm MIB and the other alarm model MIB modules is expressed by the following: The alarmModelTable has a corresponding table in the specific MIB. For each row in the specific MIB alarm model table there is one row in the alarmModelTable. The alarmActiveTable has a corresponding table in the specific MIBs. For each row in the specific MIB active alarm table, there is one row in the alarmActiveTable. The alarmModelSpecificPointer object in the alarmModelTable points to the specific model entry in an extended alarm model table corresponding to this particular alarm. The alarmActiveSpecificPointer object in the alarmActiveTable points to the specific active alarm entry in an extended active alarm table corresponding to this particular alarm instance. Additional extensions can be defined by defining an AUGEMENTATION of either the Alarm or ITU Alarm tables. As the alarm model table only provides a mechanism to point at one specific alarm model, additional specific models SHOULD define another mechanism to map from the generic alarm model to the additional model." Sharon -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Wednesday, November 12, 2003 11:39 PM To: Randy Presuhn; disman@ietf.org Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Correct, this sentence needs to be stroke out. Regards, Dan > -----Original Message----- > From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On > Behalf Of Randy Presuhn > Sent: 12 November, 2003 5:40 PM > To: disman@ietf.org > Subject: RE: [Disman] Section 5.1 in > draft-ietf-disman-alarm-mib-15.txt > > > Hi - > > I think this is much clearer, though one sentence isn't always true: > > In the case of the ITU Alarm MIB, for each row in the > alarm model table there is one row in the ITU alarm model table. > > This sentence is false for rows in the alarmModelTable where the value > of the last index is greater than six. > > Randy > > -----Original Message----- > From: Sharon Chisholm > Sent: Nov 11, 2003 1:42 PM > To: "Disman (E-mail)" > Subject: RE: [Disman] Section 5.1 in > draft-ietf-disman-alarm-mib-15.txt > > Hi > > The following is the proposed resolution to Randy-65 > Assuming no objection, > this item will be considered closed conditional on the > proposed edit being > done. > > In section 4.1.1 replace > > " The relationship between the Alarm MIB and the other alarm > model MIB > modules is expressed by the following: The alarmModelTable has a > corresponding table in the specific MIB. For each row in the > specific MIB alarm model table there is one row in the > alarmModelTable. The alarmActiveTable has a corresponding table in > the specific MIBs. For each row in the specific MIB active alarm > table, there is one row in the alarmActiveTable. The > alarmModelSpecificPointer object in the alarmModelTable points to > the specific model entry in an extended alarm model table > corresponding to this particular alarm. The > alarmActiveSpecificPointer object in the alarmActiveTable points to > the specific active alarm entry in an extended active alarm table > corresponding to this particular alarm instance. > > Additional extensions can be defined by defining an > AUGEMENTATION of > either the Alarm or ITU Alarm tables." > > With > > " The relationship between the Alarm MIB and the other alarm > model MIB > modules is expressed by the following: The alarmModelTable has a > corresponding table in the specific MIB. For each row in the > specific MIB alarm model table there is one row in the > alarmModelTable. The alarmActiveTable has a corresponding table in > the specific MIBs. For each row in the specific MIB active alarm > table, there is one row in the alarmActiveTable. The > alarmModelSpecificPointer object in the alarmModelTable points to > the specific model entry in an extended alarm model table > corresponding to this particular alarm. The > alarmActiveSpecificPointer object in the alarmActiveTable points to > the specific active alarm entry in an extended active alarm table > corresponding to this particular alarm instance. > > In the case of the ITU Alarm MIB, for each row in the > alarm model table there is one row in the ITU alarm model table. > > Additional extensions can be defined by defining an > AUGEMENTATION of > either the Alarm or ITU Alarm tables. As the alarm model table only > provides a mechanism to point at one specific alarm model, > additional specific models SHOULD define another mechanism to map > from the generic alarm model to the additional model." > > > Sharon > > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Wednesday, October 22, 2003 3:06 AM > To: Disman (E-mail) > Subject: Re: [Disman] Section 5.1 in > draft-ietf-disman-alarm-mib-15.txt > > > Hi - > > Though the final resolution of this will probably depend on > 69-1, I do have > a question / comment on this proposed change below. > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Saturday, October 18, 2003 3:32 PM > > Subject: RE: [Disman] Section 5.1 in > > draft-ietf-disman-alarm-mib-15.txt > > > > > Hi > > > > The following is the proposed resolution to Randy-65 Assuming no > > objection, this item will be considered closed conditional on the > > proposed edit being done. > > > > In section 4.1.1 replace > > > > " The relationship between the Alarm MIB and the other > alarm model MIB > > modules is expressed by the following: The alarmModelTable has a > > corresponding table in the specific MIB. For each row in the > > specific MIB alarm model table there is one row in the > > alarmModelTable. The alarmActiveTable has a > corresponding table in > > the specific MIBs. For each row in the specific MIB active alarm > > table, there is one row in the alarmActiveTable. The > > alarmModelSpecificPointer object in the alarmModelTable points to > > the specific model entry in an extended alarm model table > > corresponding to this particular alarm. The > > alarmActiveSpecificPointer object in the > alarmActiveTable points to > > the specific active alarm entry in an extended active alarm table > > corresponding to this particular alarm instance. > > > > Additional extensions can be defined by defining an > AUGEMENTATION of > > either the Alarm or ITU Alarm tables." > > > > With > > > > " The relationship between the Alarm MIB and the other > alarm model MIB > > modules is expressed by the following: The alarmModelTable has a > > corresponding table in the specific MIB. For each row in the > > specific MIB alarm model table there is one row in the > > alarmModelTable. The alarmActiveTable has a > corresponding table in > > the specific MIBs. For each row in the specific MIB active alarm > > table, there is one row in the alarmActiveTable. The > > alarmModelSpecificPointer object in the alarmModelTable points to > > the specific model entry in an extended alarm model table > > corresponding to this particular alarm. The > > alarmActiveSpecificPointer object in the > alarmActiveTable points to > > the specific active alarm entry in an extended active alarm table > > corresponding to this particular alarm instance. > > > > In the case of the ITU Alarm MIB, for each row in the > > alarm model table there is one row in the ITU alarm model table. > > If a system supports both the ITU alarm MIB and some > other alarm extension MIB, then for a given entry in the > alarmModelTable > there will be: > (a) an entry in the ITU alarm MIB, and no entry in the > other extension > MIB > (b) an entry in both MIBs' tables > > I believe the proposed text preclude the third possibility > (c) an entry in the other extension MIB, but not in the > ITU alarm MIB. > > The upshot of this, I believe, is that only extension models > corresponding > to the ITU alarm model could be defined. I don't think that > this was quite > what we meant to do. > > > Additional extensions can be defined by defining an > AUGEMENTATION of > > either the Alarm or ITU Alarm tables. As the alarm model > table only > > provides a mechanism to point at one specific alarm model, > > additional specific models SHOULD define another mechanism to map > > from the generic alarm model to the additional model." > ... > > I think that the the semantics of augmenting the Alarm table would be > different from the semantics of augmenting the ITU alarm table, and > that we shouldn't confuse the two cases. > > Randy > > > > > > > From exim@www1.ietf.org Mon Nov 17 09:00:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11947 for ; Mon, 17 Nov 2003 09:00:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjvC-00080f-Ty for disman-archive@odin.ietf.org; Mon, 17 Nov 2003 09:00:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHE06eb030767 for disman-archive@odin.ietf.org; Mon, 17 Nov 2003 09:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjvB-0007yk-6j for disman-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 09:00:05 -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 IAA11902 for ; Mon, 17 Nov 2003 08:59:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALjv9-0006rJ-00 for disman-web-archive@ietf.org; Mon, 17 Nov 2003 09:00:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALjv8-0006rG-00 for disman-web-archive@ietf.org; Mon, 17 Nov 2003 09:00:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjv9-0007xZ-0I; Mon, 17 Nov 2003 09:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjuW-0007wf-Ch for disman@optimus.ietf.org; Mon, 17 Nov 2003 08:59:24 -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 IAA11890 for ; Mon, 17 Nov 2003 08:59:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALjuU-0006r1-00 for disman@ietf.org; Mon, 17 Nov 2003 08:59:23 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ALjuU-0006qb-00 for disman@ietf.org; Mon, 17 Nov 2003 08:59:22 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAHDwo302504 for ; Mon, 17 Nov 2003 08:58:50 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Nov 2003 08:58:50 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340946415F@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt 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: Mon, 17 Nov 2003 08:58:43 -0500 Hi The following is the proposed resolution to Randy-65 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 4.1.1 replace " The relationship between the Alarm MIB and the other alarm model MIB modules is expressed by the following: The alarmModelTable has a corresponding table in the specific MIB. For each row in the specific MIB alarm model table there is one row in the alarmModelTable. The alarmActiveTable has a corresponding table in the specific MIBs. For each row in the specific MIB active alarm table, there is one row in the alarmActiveTable. The alarmModelSpecificPointer object in the alarmModelTable points to the specific model entry in an extended alarm model table corresponding to this particular alarm. The alarmActiveSpecificPointer object in the alarmActiveTable points to the specific active alarm entry in an extended active alarm table corresponding to this particular alarm instance. Additional extensions can be defined by defining an AUGEMENTATION of either the Alarm or ITU Alarm tables." With " The relationship between the Alarm MIB and the other alarm model MIB modules is expressed by the following: The alarmModelTable has a corresponding table in the specific MIB. For each row in the specific MIB alarm model table there is one row in the alarmModelTable. The alarmActiveTable has a corresponding table in the specific MIBs. For each row in the specific MIB active alarm table, there is one row in the alarmActiveTable. The alarmModelSpecificPointer object in the alarmModelTable points to the specific model entry in an extended alarm model table corresponding to this particular alarm. The alarmActiveSpecificPointer object in the alarmActiveTable points to the specific active alarm entry in an extended active alarm table corresponding to this particular alarm instance. Additional extensions can be defined by defining an AUGEMENTATION of either the Alarm or ITU Alarm tables. As the alarm model table only provides a mechanism to point at one specific alarm model, additional specific models SHOULD define another mechanism to map from the generic alarm model to the additional model." Sharon -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Wednesday, November 12, 2003 11:39 PM To: Randy Presuhn; disman@ietf.org Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Correct, this sentence needs to be stroke out. Regards, Dan > -----Original Message----- > From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On > Behalf Of Randy Presuhn > Sent: 12 November, 2003 5:40 PM > To: disman@ietf.org > Subject: RE: [Disman] Section 5.1 in > draft-ietf-disman-alarm-mib-15.txt > > > Hi - > > I think this is much clearer, though one sentence isn't always true: > > In the case of the ITU Alarm MIB, for each row in the > alarm model table there is one row in the ITU alarm model table. > > This sentence is false for rows in the alarmModelTable where the value > of the last index is greater than six. > > Randy > > -----Original Message----- > From: Sharon Chisholm > Sent: Nov 11, 2003 1:42 PM > To: "Disman (E-mail)" > Subject: RE: [Disman] Section 5.1 in > draft-ietf-disman-alarm-mib-15.txt > > Hi > > The following is the proposed resolution to Randy-65 > Assuming no objection, > this item will be considered closed conditional on the > proposed edit being > done. > > In section 4.1.1 replace > > " The relationship between the Alarm MIB and the other alarm > model MIB > modules is expressed by the following: The alarmModelTable has a > corresponding table in the specific MIB. For each row in the > specific MIB alarm model table there is one row in the > alarmModelTable. The alarmActiveTable has a corresponding table in > the specific MIBs. For each row in the specific MIB active alarm > table, there is one row in the alarmActiveTable. The > alarmModelSpecificPointer object in the alarmModelTable points to > the specific model entry in an extended alarm model table > corresponding to this particular alarm. The > alarmActiveSpecificPointer object in the alarmActiveTable points to > the specific active alarm entry in an extended active alarm table > corresponding to this particular alarm instance. > > Additional extensions can be defined by defining an > AUGEMENTATION of > either the Alarm or ITU Alarm tables." > > With > > " The relationship between the Alarm MIB and the other alarm > model MIB > modules is expressed by the following: The alarmModelTable has a > corresponding table in the specific MIB. For each row in the > specific MIB alarm model table there is one row in the > alarmModelTable. The alarmActiveTable has a corresponding table in > the specific MIBs. For each row in the specific MIB active alarm > table, there is one row in the alarmActiveTable. The > alarmModelSpecificPointer object in the alarmModelTable points to > the specific model entry in an extended alarm model table > corresponding to this particular alarm. The > alarmActiveSpecificPointer object in the alarmActiveTable points to > the specific active alarm entry in an extended active alarm table > corresponding to this particular alarm instance. > > In the case of the ITU Alarm MIB, for each row in the > alarm model table there is one row in the ITU alarm model table. > > Additional extensions can be defined by defining an > AUGEMENTATION of > either the Alarm or ITU Alarm tables. As the alarm model table only > provides a mechanism to point at one specific alarm model, > additional specific models SHOULD define another mechanism to map > from the generic alarm model to the additional model." > > > Sharon > > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Wednesday, October 22, 2003 3:06 AM > To: Disman (E-mail) > Subject: Re: [Disman] Section 5.1 in > draft-ietf-disman-alarm-mib-15.txt > > > Hi - > > Though the final resolution of this will probably depend on > 69-1, I do have > a question / comment on this proposed change below. > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Saturday, October 18, 2003 3:32 PM > > Subject: RE: [Disman] Section 5.1 in > > draft-ietf-disman-alarm-mib-15.txt > > > > > Hi > > > > The following is the proposed resolution to Randy-65 Assuming no > > objection, this item will be considered closed conditional on the > > proposed edit being done. > > > > In section 4.1.1 replace > > > > " The relationship between the Alarm MIB and the other > alarm model MIB > > modules is expressed by the following: The alarmModelTable has a > > corresponding table in the specific MIB. For each row in the > > specific MIB alarm model table there is one row in the > > alarmModelTable. The alarmActiveTable has a > corresponding table in > > the specific MIBs. For each row in the specific MIB active alarm > > table, there is one row in the alarmActiveTable. The > > alarmModelSpecificPointer object in the alarmModelTable points to > > the specific model entry in an extended alarm model table > > corresponding to this particular alarm. The > > alarmActiveSpecificPointer object in the > alarmActiveTable points to > > the specific active alarm entry in an extended active alarm table > > corresponding to this particular alarm instance. > > > > Additional extensions can be defined by defining an > AUGEMENTATION of > > either the Alarm or ITU Alarm tables." > > > > With > > > > " The relationship between the Alarm MIB and the other > alarm model MIB > > modules is expressed by the following: The alarmModelTable has a > > corresponding table in the specific MIB. For each row in the > > specific MIB alarm model table there is one row in the > > alarmModelTable. The alarmActiveTable has a > corresponding table in > > the specific MIBs. For each row in the specific MIB active alarm > > table, there is one row in the alarmActiveTable. The > > alarmModelSpecificPointer object in the alarmModelTable points to > > the specific model entry in an extended alarm model table > > corresponding to this particular alarm. The > > alarmActiveSpecificPointer object in the > alarmActiveTable points to > > the specific active alarm entry in an extended active alarm table > > corresponding to this particular alarm instance. > > > > In the case of the ITU Alarm MIB, for each row in the > > alarm model table there is one row in the ITU alarm model table. > > If a system supports both the ITU alarm MIB and some > other alarm extension MIB, then for a given entry in the > alarmModelTable > there will be: > (a) an entry in the ITU alarm MIB, and no entry in the > other extension > MIB > (b) an entry in both MIBs' tables > > I believe the proposed text preclude the third possibility > (c) an entry in the other extension MIB, but not in the > ITU alarm MIB. > > The upshot of this, I believe, is that only extension models > corresponding > to the ITU alarm model could be defined. I don't think that > this was quite > what we meant to do. > > > Additional extensions can be defined by defining an > AUGEMENTATION of > > either the Alarm or ITU Alarm tables. As the alarm model > table only > > provides a mechanism to point at one specific alarm model, > > additional specific models SHOULD define another mechanism to map > > from the generic alarm model to the additional model." > ... > > I think that the the semantics of augmenting the Alarm table would be > different from the semantics of augmenting the ITU alarm table, and > that we shouldn't confuse the two cases. > > Randy > > > > > > > From disman-admin@ietf.org Mon Nov 17 09:09:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12161 for ; Mon, 17 Nov 2003 09:09:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALk3o-0008Vz-AN; Mon, 17 Nov 2003 09:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALk3i-0008Vm-9n for disman@optimus.ietf.org; Mon, 17 Nov 2003 09:08:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12143 for ; Mon, 17 Nov 2003 09:08:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALk3g-0006y7-00 for disman@ietf.org; Mon, 17 Nov 2003 09:08:52 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ALk3f-0006xl-00 for disman@ietf.org; Mon, 17 Nov 2003 09:08:51 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAHE8Jh08792 for ; Mon, 17 Nov 2003 09:08:19 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Nov 2003 09:08:19 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409464185@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Subject: RE: [Disman] "table wrapping" in alarm MIB -15- 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: Mon, 17 Nov 2003 09:08:15 -0500 Hi The following is the proposed resolution to Randy-75-4 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the definition of alarmActiveEntry replace "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared." With "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared. If under extreme resource constraint the system is unable to add any more entries into this table, then the alarmActiveOverflow statistic will be increased by one." Add new item alarmActiveOverflow OBJECT-TYPE SYNTAX Counter32 UNITS "active alarms" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of active alarms that have not been put into the alarmActiveTable since system restart as a result of extreme resource constraints." ::= { alarmActive 5 } Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, November 12, 2003 10:17 AM To: disman@ietf.org Subject: RE: [Disman] "table wrapping" in alarm MIB -15- Hi - This looks ok to me. I'd suggest putting a UNITS on the proposed counter. Randy -----Original Message----- From: Sharon Chisholm Sent: Nov 11, 2003 12:23 PM To: "Disman (E-mail)" Subject: RE: [Disman] "table wrapping" in alarm MIB -15- Hi The following is the proposed resolution to Randy-75-4 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the definition of alarmActiveEntry replace "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared." With "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared. If under extreme resource constraint the system is unable to add any more entries into this table, then the alarmActiveOverflow statistic will be increased by one." Add new item alarmActiveOverflow OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of active alarms that have not been put into the alarmActiveTable since system restart as a result of extreme resource constraints." ::= { alarmActive 5 } Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 21, 2003 11:14 PM To: Disman (E-mail) Subject: Re: [Disman] "table wrapping" in alarm MIB -15- Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Tuesday, October 21, 2003 7:30 PM > Subject: RE: [Disman] "table wrapping" in alarm MIB -15- ... > I think we are in danger of fundamentally changing the architecture of > this 'active alarm' list for the sake of a corner case. It's not like > we didn't think of this, but rather that we didn't want an > architecture that encouraged partial active alarm lists. > > What exactly is the wg chair looking for with this? ... The chair wants the guy the AD asked to review the document to be happy. He'd like text that says what happens when an alarm model entry matches a notification delivered to the alarm inrastructure, and there is not sufficient storage (or other resources) available to create a new alarm entry. Possibilities: - no alarm entry is created - some alarm entry is deleted or cleared to make room (algorithm needs to be spelled out) - something records that this has happened My personal opinion is that creating no entry, and recording that fact in a counter is probably a reasonable solution, but am open to other possibilities. We went through the design issues in the log MIB. I suspect the tradeoffs are very similar here. This reviewer will be happy as long as the MIB is explicit about what happens; I think this MIB's proponents will figure out what the best thing would be to do when storage is exhausted. I agree that it's desirable to not encourage partial active alarm lists, but I also want *realistic* standards, i.e., no assumptions that storage is infinite. Randy (In all his roles. :-) From exim@www1.ietf.org Mon Nov 17 09:09:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12185 for ; Mon, 17 Nov 2003 09:09:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALk3q-00005v-Q2 for disman-archive@odin.ietf.org; Mon, 17 Nov 2003 09:09:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHE92VF000357 for disman-archive@odin.ietf.org; Mon, 17 Nov 2003 09:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALk3q-00005g-Md for disman-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 09:09:02 -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 JAA12147 for ; Mon, 17 Nov 2003 09:08:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALk3p-0006yE-00 for disman-web-archive@ietf.org; Mon, 17 Nov 2003 09:09:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALk3o-0006yB-00 for disman-web-archive@ietf.org; Mon, 17 Nov 2003 09:09:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALk3o-0008Vz-AN; Mon, 17 Nov 2003 09:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALk3i-0008Vm-9n for disman@optimus.ietf.org; Mon, 17 Nov 2003 09:08:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12143 for ; Mon, 17 Nov 2003 09:08:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALk3g-0006y7-00 for disman@ietf.org; Mon, 17 Nov 2003 09:08:52 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ALk3f-0006xl-00 for disman@ietf.org; Mon, 17 Nov 2003 09:08:51 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAHE8Jh08792 for ; Mon, 17 Nov 2003 09:08:19 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Nov 2003 09:08:19 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409464185@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Subject: RE: [Disman] "table wrapping" in alarm MIB -15- 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: Mon, 17 Nov 2003 09:08:15 -0500 Hi The following is the proposed resolution to Randy-75-4 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the definition of alarmActiveEntry replace "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared." With "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared. If under extreme resource constraint the system is unable to add any more entries into this table, then the alarmActiveOverflow statistic will be increased by one." Add new item alarmActiveOverflow OBJECT-TYPE SYNTAX Counter32 UNITS "active alarms" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of active alarms that have not been put into the alarmActiveTable since system restart as a result of extreme resource constraints." ::= { alarmActive 5 } Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, November 12, 2003 10:17 AM To: disman@ietf.org Subject: RE: [Disman] "table wrapping" in alarm MIB -15- Hi - This looks ok to me. I'd suggest putting a UNITS on the proposed counter. Randy -----Original Message----- From: Sharon Chisholm Sent: Nov 11, 2003 12:23 PM To: "Disman (E-mail)" Subject: RE: [Disman] "table wrapping" in alarm MIB -15- Hi The following is the proposed resolution to Randy-75-4 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the definition of alarmActiveEntry replace "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared." With "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared. If under extreme resource constraint the system is unable to add any more entries into this table, then the alarmActiveOverflow statistic will be increased by one." Add new item alarmActiveOverflow OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of active alarms that have not been put into the alarmActiveTable since system restart as a result of extreme resource constraints." ::= { alarmActive 5 } Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 21, 2003 11:14 PM To: Disman (E-mail) Subject: Re: [Disman] "table wrapping" in alarm MIB -15- Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Tuesday, October 21, 2003 7:30 PM > Subject: RE: [Disman] "table wrapping" in alarm MIB -15- ... > I think we are in danger of fundamentally changing the architecture of > this 'active alarm' list for the sake of a corner case. It's not like > we didn't think of this, but rather that we didn't want an > architecture that encouraged partial active alarm lists. > > What exactly is the wg chair looking for with this? ... The chair wants the guy the AD asked to review the document to be happy. He'd like text that says what happens when an alarm model entry matches a notification delivered to the alarm inrastructure, and there is not sufficient storage (or other resources) available to create a new alarm entry. Possibilities: - no alarm entry is created - some alarm entry is deleted or cleared to make room (algorithm needs to be spelled out) - something records that this has happened My personal opinion is that creating no entry, and recording that fact in a counter is probably a reasonable solution, but am open to other possibilities. We went through the design issues in the log MIB. I suspect the tradeoffs are very similar here. This reviewer will be happy as long as the MIB is explicit about what happens; I think this MIB's proponents will figure out what the best thing would be to do when storage is exhausted. I agree that it's desirable to not encourage partial active alarm lists, but I also want *realistic* standards, i.e., no assumptions that storage is infinite. Randy (In all his roles. :-) From disman-admin@ietf.org Mon Nov 17 12:46:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24407 for ; Mon, 17 Nov 2003 12:46:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALnRq-0003Io-BM; Mon, 17 Nov 2003 12:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALnR3-0003I6-Jt for disman@optimus.ietf.org; Mon, 17 Nov 2003 12:45:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24360 for ; Mon, 17 Nov 2003 12:45:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALnR1-0002ug-00 for disman@ietf.org; Mon, 17 Nov 2003 12:45:11 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ALnR1-0002uJ-00 for disman@ietf.org; Mon, 17 Nov 2003 12:45:11 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAHHid321921 for ; Mon, 17 Nov 2003 12:44:40 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Nov 2003 12:44:40 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34094644D0@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Subject: RE: [Disman] alarm comment 69-1 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: Mon, 17 Nov 2003 12:44:30 -0500 hi The following is the proposed resolution to Randy-69-1 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. Replace ituAlarmEntry OBJECT-TYPE SYNTAX ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table for each possible alarm severity. This table MUST be persistent across system reboots." INDEX { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity } ::= { ituAlarmTable 1 } With ituAlarmEntry OBJECT-TYPE SYNTAX ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table whenever an entry is created in the alarmModelTable with a value of alarmModelState in the range from 1 to 6. Entries disappear from this table whenever the corresponding entries are deleted from the alarmModelTable, including in cases where those entries have been deleted due to local system action. The value of alarmModelSpecificPointer has no effect on the creation or deletion of entries in this table. Values of alarmModelState map to values of ituAlarmPerceivedSeverity as follows: alarmModelState -> ituAlarmPerceivedSeverity 1 -> clear (1) 2 -> indeterminate (2) 3 -> warning (6) 4 -> minor (5) 5 -> major (4) 6 -> critical (3) All other values of alarmModelState MUST NOT appear in this table. This table MUST be persistent across system reboots." INDEX { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity } ::= { ituAlarmTable 1 } On the description of alarmModelSpecificPointer, replace "If no additional, model-specific Alarm MIB is supported by the system the value of this object is `0.0'. When a model-specific Alarm MIB is supported, this object is the instance pointer to the model-specific alarm definition." With "If no additional, model-specific Alarm MIB is supported by the system the value of this object is `0.0'and attempts to set it to any other value MUST be rejected appropriately. When a model-specific Alarm MIB is supported, this object MUST refer to the first accessible object in a corresponding row of the model definition in one of these model-specific MIBs and attempts to set this object to { 0 0 } or any other value MUST be rejected appropriately." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, November 11, 2003 1:56 PM To: disman@ietf.org Subject: RE: [Disman] alarm comment 69-1 Hi - As technical contributor: Although I *really* dislike the amount of magic this requires, in the interest of getting this thing out, I'm willing to give up on this issue *if* the language is tightened up *and* the constraints on alarmModelSpecificPointer are spelled out. Specific changes I'd like to see to the proposal: ituAlarmEntry OBJECT-TYPE SYNTAX ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table whenever an entry is created in the alarmModelTable with a value of alarmModelState in the range from 1 to 6. Entries disappear from this table whenever the corresponding entries are deleted from the alarmModelTable, including in cases where those entries have been deleted due to local system action. The value of alarmModelSpecificPointer has no effect on the creation or deletion of entries in this table. Values of alarmModelState map to values of ituAlarmPerceivedSeverity as follows: alarmModelState -> ituAlarmPerceivedSeverity 1 -> clear (1) 2 -> indeterminate (2) 3 -> warning (6) 4 -> minor (5) 5 -> major (4) 6 -> critical (3) Any other values of alarmModelState MUST NOT appear in this table, since the SYNTAX of ituAlarmPerceivedSeverity is limited to this range. This table MUST be persistent across system reboots, but this persistence MUST NOT result in a situation in which an entry exists in this table without a corresponding entry in the alarmModelTable." INDEX { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity } ::= { ituAlarmTable 1 }" Likewise, if we're going to go with this approach, I'd like to see the DESCRIPTION of alarmModelSpecificPointer clarified to say something like: "If no additional, model-specific Alarm MIB is supported by the system, the value of this object MUST be { 0 0 }, and attempts to set it to any other value MUST be rejected appropriately. If the system does support one or more model-specific Alarm MIBs, then, if creation of this row would result in creation of a row in one or more model-specific alarm MIBs, the value to which this object is set MUST refer to the first accessible object in a corresponding row of the model definition in one of these model-specific MIBs; attempts to set this object to { 0 0 } or any other value MUST be rejected appropriately. When a model-specific Alarm MIB is supported, this object is the instance pointer to the model-specific alarm definition." As WG chair: These words could use some polish, but we do need to make a serious attempt to ensure that our definitions are sufficiently precise to make interoperation of implementations reasonably likely. The semantics Randy spelled out were his *guess* as to what the current i-d intended. If he got it wrong, that's just one more reason to make the intent *clear* and *explicit*. Randy From exim@www1.ietf.org Mon Nov 17 12:46:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24422 for ; Mon, 17 Nov 2003 12:46:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALnRv-0003Jd-A2 for disman-archive@odin.ietf.org; Mon, 17 Nov 2003 12:46:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHHk7Gq012742 for disman-archive@odin.ietf.org; Mon, 17 Nov 2003 12:46:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALnRv-0003JR-53 for disman-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 12:46:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24398 for ; Mon, 17 Nov 2003 12:45:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALnRt-0002wD-00 for disman-web-archive@ietf.org; Mon, 17 Nov 2003 12:46:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALnRt-0002w7-00 for disman-web-archive@ietf.org; Mon, 17 Nov 2003 12:46:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALnRq-0003Io-BM; Mon, 17 Nov 2003 12:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALnR3-0003I6-Jt for disman@optimus.ietf.org; Mon, 17 Nov 2003 12:45:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24360 for ; Mon, 17 Nov 2003 12:45:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALnR1-0002ug-00 for disman@ietf.org; Mon, 17 Nov 2003 12:45:11 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ALnR1-0002uJ-00 for disman@ietf.org; Mon, 17 Nov 2003 12:45:11 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAHHid321921 for ; Mon, 17 Nov 2003 12:44:40 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Nov 2003 12:44:40 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34094644D0@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Subject: RE: [Disman] alarm comment 69-1 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: Mon, 17 Nov 2003 12:44:30 -0500 hi The following is the proposed resolution to Randy-69-1 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. Replace ituAlarmEntry OBJECT-TYPE SYNTAX ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table for each possible alarm severity. This table MUST be persistent across system reboots." INDEX { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity } ::= { ituAlarmTable 1 } With ituAlarmEntry OBJECT-TYPE SYNTAX ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table whenever an entry is created in the alarmModelTable with a value of alarmModelState in the range from 1 to 6. Entries disappear from this table whenever the corresponding entries are deleted from the alarmModelTable, including in cases where those entries have been deleted due to local system action. The value of alarmModelSpecificPointer has no effect on the creation or deletion of entries in this table. Values of alarmModelState map to values of ituAlarmPerceivedSeverity as follows: alarmModelState -> ituAlarmPerceivedSeverity 1 -> clear (1) 2 -> indeterminate (2) 3 -> warning (6) 4 -> minor (5) 5 -> major (4) 6 -> critical (3) All other values of alarmModelState MUST NOT appear in this table. This table MUST be persistent across system reboots." INDEX { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity } ::= { ituAlarmTable 1 } On the description of alarmModelSpecificPointer, replace "If no additional, model-specific Alarm MIB is supported by the system the value of this object is `0.0'. When a model-specific Alarm MIB is supported, this object is the instance pointer to the model-specific alarm definition." With "If no additional, model-specific Alarm MIB is supported by the system the value of this object is `0.0'and attempts to set it to any other value MUST be rejected appropriately. When a model-specific Alarm MIB is supported, this object MUST refer to the first accessible object in a corresponding row of the model definition in one of these model-specific MIBs and attempts to set this object to { 0 0 } or any other value MUST be rejected appropriately." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, November 11, 2003 1:56 PM To: disman@ietf.org Subject: RE: [Disman] alarm comment 69-1 Hi - As technical contributor: Although I *really* dislike the amount of magic this requires, in the interest of getting this thing out, I'm willing to give up on this issue *if* the language is tightened up *and* the constraints on alarmModelSpecificPointer are spelled out. Specific changes I'd like to see to the proposal: ituAlarmEntry OBJECT-TYPE SYNTAX ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table whenever an entry is created in the alarmModelTable with a value of alarmModelState in the range from 1 to 6. Entries disappear from this table whenever the corresponding entries are deleted from the alarmModelTable, including in cases where those entries have been deleted due to local system action. The value of alarmModelSpecificPointer has no effect on the creation or deletion of entries in this table. Values of alarmModelState map to values of ituAlarmPerceivedSeverity as follows: alarmModelState -> ituAlarmPerceivedSeverity 1 -> clear (1) 2 -> indeterminate (2) 3 -> warning (6) 4 -> minor (5) 5 -> major (4) 6 -> critical (3) Any other values of alarmModelState MUST NOT appear in this table, since the SYNTAX of ituAlarmPerceivedSeverity is limited to this range. This table MUST be persistent across system reboots, but this persistence MUST NOT result in a situation in which an entry exists in this table without a corresponding entry in the alarmModelTable." INDEX { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity } ::= { ituAlarmTable 1 }" Likewise, if we're going to go with this approach, I'd like to see the DESCRIPTION of alarmModelSpecificPointer clarified to say something like: "If no additional, model-specific Alarm MIB is supported by the system, the value of this object MUST be { 0 0 }, and attempts to set it to any other value MUST be rejected appropriately. If the system does support one or more model-specific Alarm MIBs, then, if creation of this row would result in creation of a row in one or more model-specific alarm MIBs, the value to which this object is set MUST refer to the first accessible object in a corresponding row of the model definition in one of these model-specific MIBs; attempts to set this object to { 0 0 } or any other value MUST be rejected appropriately. When a model-specific Alarm MIB is supported, this object is the instance pointer to the model-specific alarm definition." As WG chair: These words could use some polish, but we do need to make a serious attempt to ensure that our definitions are sufficiently precise to make interoperation of implementations reasonably likely. The semantics Randy spelled out were his *guess* as to what the current i-d intended. If he got it wrong, that's just one more reason to make the intent *clear* and *explicit*. Randy From disman-admin@ietf.org Mon Nov 17 15:38:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03807 for ; Mon, 17 Nov 2003 15:38:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALq8H-0004XD-E2; Mon, 17 Nov 2003 15:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALq7s-0004Q3-DU for disman@optimus.ietf.org; Mon, 17 Nov 2003 15:37:36 -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 PAA03796 for ; Mon, 17 Nov 2003 15:37:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALq7q-0005mM-00 for disman@ietf.org; Mon, 17 Nov 2003 15:37:34 -0500 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1ALq7q-0005mJ-00 for disman@ietf.org; Mon, 17 Nov 2003 15:37:34 -0500 Received: from h-68-164-85-110.snvacaid.dynamic.covad.net ([68.164.85.110] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ALq7n-0001Mn-00 for disman@ietf.org; Mon, 17 Nov 2003 12:37:31 -0800 Message-ID: <002401c3ad4a$db36e960$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <3549C09B853DD5119B540002A52CDD34094644D0@zcard0ka.ca.nortel.com> Subject: Re: [Disman] alarm comment 69-1 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, 17 Nov 2003 12:39:10 -0800 Hi - Looks good to me. Thanks! Randy ----- Original Message ----- > From: "Sharon Chisholm" > To: > Sent: Monday, November 17, 2003 9:44 AM > Subject: RE: [Disman] alarm comment 69-1 > > hi > > The following is the proposed resolution to Randy-69-1 Assuming no > objection, this item will be considered closed conditional on the > proposed edit being done. > > Replace > > > ituAlarmEntry OBJECT-TYPE > SYNTAX ItuAlarmEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Entries appear in this table for each possible alarm > severity. > This table MUST be persistent across system reboots." > INDEX { alarmListName, alarmModelIndex, > ituAlarmPerceivedSeverity } > ::= { ituAlarmTable 1 } > > With > > > ituAlarmEntry OBJECT-TYPE > SYNTAX ItuAlarmEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Entries appear in this table whenever an entry is created > in the alarmModelTable with a value of alarmModelState in > the range from 1 to 6. Entries disappear from this table > whenever the corresponding entries are deleted from the > alarmModelTable, including in cases where those entries have > been deleted due to local system action. The value of > alarmModelSpecificPointer has no effect on the creation > or deletion of entries in this table. Values of > alarmModelState map to values of ituAlarmPerceivedSeverity > as follows: > > alarmModelState -> ituAlarmPerceivedSeverity > 1 -> clear (1) > 2 -> indeterminate (2) > 3 -> warning (6) > 4 -> minor (5) > 5 -> major (4) > 6 -> critical (3) > > All other values of alarmModelState MUST NOT appear > in this table. > > This table MUST be persistent across system reboots." > INDEX { alarmListName, alarmModelIndex, > ituAlarmPerceivedSeverity } > ::= { ituAlarmTable 1 } > > On the description of alarmModelSpecificPointer, replace > > "If no additional, model-specific Alarm MIB is supported by the > system the value of this object is `0.0'. When a model-specific > Alarm MIB is supported, this object is the instance pointer to > the model-specific alarm definition." > > With > > "If no additional, model-specific Alarm MIB is supported by the > system the value of this object is `0.0'and attempts > to set it to any other value MUST be rejected appropriately. > > When a model-specific Alarm MIB is supported, this object MUST > refer to the first accessible object in a corresponding > row of the model definition in one of these model-specific MIBs > and attempts to set this object to { 0 0 } or any other > value MUST be rejected appropriately." > > Sharon > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Tuesday, November 11, 2003 1:56 PM > To: disman@ietf.org > Subject: RE: [Disman] alarm comment 69-1 > > > Hi - > > As technical contributor: > > Although I *really* dislike the amount of magic this requires, in the > interest of getting this thing out, I'm willing to give up on this issue > *if* the language is tightened up *and* the constraints on > alarmModelSpecificPointer are spelled out. > > Specific changes I'd like to see to the proposal: > > ituAlarmEntry OBJECT-TYPE > SYNTAX ItuAlarmEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Entries appear in this table whenever an entry is created > in the alarmModelTable with a value of alarmModelState in > the range from 1 to 6. Entries disappear from this table > whenever the corresponding entries are deleted from the > alarmModelTable, including in cases where those entries have > been deleted due to local system action. The value of > alarmModelSpecificPointer has no effect on the creation > or deletion of entries in this table. > Values of alarmModelState map to values of > ituAlarmPerceivedSeverity as follows: > > alarmModelState -> ituAlarmPerceivedSeverity > 1 -> clear (1) > 2 -> indeterminate (2) > 3 -> warning (6) > 4 -> minor (5) > 5 -> major (4) > 6 -> critical (3) > > Any other values of alarmModelState MUST NOT appear > in this table, since the SYNTAX of ituAlarmPerceivedSeverity > is limited to this range. > > This table MUST be persistent across system reboots, but > this persistence MUST NOT result in a situation in which an > entry exists in this table without a corresponding entry in > the alarmModelTable." > INDEX { alarmListName, alarmModelIndex, > ituAlarmPerceivedSeverity } > ::= { ituAlarmTable 1 }" > > Likewise, if we're going to go with this approach, I'd like to see the > DESCRIPTION of alarmModelSpecificPointer clarified to say something > like: > "If no additional, model-specific Alarm MIB is supported by the > system, the value of this object MUST be { 0 0 }, and attempts > to set it to any other value MUST be rejected appropriately. If > the system does support one or more model-specific Alarm MIBs, > then, if creation of this row would result in creation of a row in one > or more model-specific alarm MIBs, the value to which this object > is set MUST refer to the first accessible object in a corresponding > row of the model definition in one of these model-specific MIBs; > attempts to set this object to { 0 0 } or any other > value MUST be rejected appropriately. When a model-specific > Alarm MIB is supported, this object is the instance pointer to > the model-specific alarm definition." > > As WG chair: > > These words could use some polish, but we do need to make a serious attempt > to ensure that our definitions are sufficiently precise to make > interoperation of implementations reasonably likely. The semantics Randy > spelled out were his *guess* as to what the current i-d intended. If he got > it wrong, that's just one more reason to make the intent *clear* and > *explicit*. > > Randy > > From exim@www1.ietf.org Mon Nov 17 15:38:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03858 for ; Mon, 17 Nov 2003 15:38:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALq8q-0004aZ-Bc for disman-archive@odin.ietf.org; Mon, 17 Nov 2003 15:38:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHKcaOA017633 for disman-archive@odin.ietf.org; Mon, 17 Nov 2003 15:38:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALq8q-0004aK-7p for disman-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 15:38:36 -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 PAA03823 for ; Mon, 17 Nov 2003 15:38:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALq8o-0005mz-00 for disman-web-archive@ietf.org; Mon, 17 Nov 2003 15:38:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALq8o-0005mk-00 for disman-web-archive@ietf.org; Mon, 17 Nov 2003 15:38:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALq8H-0004XD-E2; Mon, 17 Nov 2003 15:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALq7s-0004Q3-DU for disman@optimus.ietf.org; Mon, 17 Nov 2003 15:37:36 -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 PAA03796 for ; Mon, 17 Nov 2003 15:37:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALq7q-0005mM-00 for disman@ietf.org; Mon, 17 Nov 2003 15:37:34 -0500 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1ALq7q-0005mJ-00 for disman@ietf.org; Mon, 17 Nov 2003 15:37:34 -0500 Received: from h-68-164-85-110.snvacaid.dynamic.covad.net ([68.164.85.110] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ALq7n-0001Mn-00 for disman@ietf.org; Mon, 17 Nov 2003 12:37:31 -0800 Message-ID: <002401c3ad4a$db36e960$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <3549C09B853DD5119B540002A52CDD34094644D0@zcard0ka.ca.nortel.com> Subject: Re: [Disman] alarm comment 69-1 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, 17 Nov 2003 12:39:10 -0800 Hi - Looks good to me. Thanks! Randy ----- Original Message ----- > From: "Sharon Chisholm" > To: > Sent: Monday, November 17, 2003 9:44 AM > Subject: RE: [Disman] alarm comment 69-1 > > hi > > The following is the proposed resolution to Randy-69-1 Assuming no > objection, this item will be considered closed conditional on the > proposed edit being done. > > Replace > > > ituAlarmEntry OBJECT-TYPE > SYNTAX ItuAlarmEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Entries appear in this table for each possible alarm > severity. > This table MUST be persistent across system reboots." > INDEX { alarmListName, alarmModelIndex, > ituAlarmPerceivedSeverity } > ::= { ituAlarmTable 1 } > > With > > > ituAlarmEntry OBJECT-TYPE > SYNTAX ItuAlarmEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Entries appear in this table whenever an entry is created > in the alarmModelTable with a value of alarmModelState in > the range from 1 to 6. Entries disappear from this table > whenever the corresponding entries are deleted from the > alarmModelTable, including in cases where those entries have > been deleted due to local system action. The value of > alarmModelSpecificPointer has no effect on the creation > or deletion of entries in this table. Values of > alarmModelState map to values of ituAlarmPerceivedSeverity > as follows: > > alarmModelState -> ituAlarmPerceivedSeverity > 1 -> clear (1) > 2 -> indeterminate (2) > 3 -> warning (6) > 4 -> minor (5) > 5 -> major (4) > 6 -> critical (3) > > All other values of alarmModelState MUST NOT appear > in this table. > > This table MUST be persistent across system reboots." > INDEX { alarmListName, alarmModelIndex, > ituAlarmPerceivedSeverity } > ::= { ituAlarmTable 1 } > > On the description of alarmModelSpecificPointer, replace > > "If no additional, model-specific Alarm MIB is supported by the > system the value of this object is `0.0'. When a model-specific > Alarm MIB is supported, this object is the instance pointer to > the model-specific alarm definition." > > With > > "If no additional, model-specific Alarm MIB is supported by the > system the value of this object is `0.0'and attempts > to set it to any other value MUST be rejected appropriately. > > When a model-specific Alarm MIB is supported, this object MUST > refer to the first accessible object in a corresponding > row of the model definition in one of these model-specific MIBs > and attempts to set this object to { 0 0 } or any other > value MUST be rejected appropriately." > > Sharon > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Tuesday, November 11, 2003 1:56 PM > To: disman@ietf.org > Subject: RE: [Disman] alarm comment 69-1 > > > Hi - > > As technical contributor: > > Although I *really* dislike the amount of magic this requires, in the > interest of getting this thing out, I'm willing to give up on this issue > *if* the language is tightened up *and* the constraints on > alarmModelSpecificPointer are spelled out. > > Specific changes I'd like to see to the proposal: > > ituAlarmEntry OBJECT-TYPE > SYNTAX ItuAlarmEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Entries appear in this table whenever an entry is created > in the alarmModelTable with a value of alarmModelState in > the range from 1 to 6. Entries disappear from this table > whenever the corresponding entries are deleted from the > alarmModelTable, including in cases where those entries have > been deleted due to local system action. The value of > alarmModelSpecificPointer has no effect on the creation > or deletion of entries in this table. > Values of alarmModelState map to values of > ituAlarmPerceivedSeverity as follows: > > alarmModelState -> ituAlarmPerceivedSeverity > 1 -> clear (1) > 2 -> indeterminate (2) > 3 -> warning (6) > 4 -> minor (5) > 5 -> major (4) > 6 -> critical (3) > > Any other values of alarmModelState MUST NOT appear > in this table, since the SYNTAX of ituAlarmPerceivedSeverity > is limited to this range. > > This table MUST be persistent across system reboots, but > this persistence MUST NOT result in a situation in which an > entry exists in this table without a corresponding entry in > the alarmModelTable." > INDEX { alarmListName, alarmModelIndex, > ituAlarmPerceivedSeverity } > ::= { ituAlarmTable 1 }" > > Likewise, if we're going to go with this approach, I'd like to see the > DESCRIPTION of alarmModelSpecificPointer clarified to say something > like: > "If no additional, model-specific Alarm MIB is supported by the > system, the value of this object MUST be { 0 0 }, and attempts > to set it to any other value MUST be rejected appropriately. If > the system does support one or more model-specific Alarm MIBs, > then, if creation of this row would result in creation of a row in one > or more model-specific alarm MIBs, the value to which this object > is set MUST refer to the first accessible object in a corresponding > row of the model definition in one of these model-specific MIBs; > attempts to set this object to { 0 0 } or any other > value MUST be rejected appropriately. When a model-specific > Alarm MIB is supported, this object is the instance pointer to > the model-specific alarm definition." > > As WG chair: > > These words could use some polish, but we do need to make a serious attempt > to ensure that our definitions are sufficiently precise to make > interoperation of implementations reasonably likely. The semantics Randy > spelled out were his *guess* as to what the current i-d intended. If he got > it wrong, that's just one more reason to make the intent *clear* and > *explicit*. > > Randy > > From disman-admin@ietf.org Wed Nov 19 10:17:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21297 for ; Wed, 19 Nov 2003 10:17:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMU4i-0000eS-VQ; Wed, 19 Nov 2003 10:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMU4S-0000eB-KW for disman@optimus.ietf.org; Wed, 19 Nov 2003 10:16:44 -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 KAA21204 for ; Wed, 19 Nov 2003 10:16:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMU4Q-0000x0-00 for disman@ietf.org; Wed, 19 Nov 2003 10:16:42 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AMU4P-0000u8-00 for disman@ietf.org; Wed, 19 Nov 2003 10:16:41 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAJFGA522903 for ; Wed, 19 Nov 2003 10:16:10 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Nov 2003 10:16:10 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34094E446E@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Closed item from Randy's Review 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, 19 Nov 2003 10:16:08 -0500 Hi Current Score: The following items are closed: 1-10, 13, 15-23, 25, 27, 29-34, 36-38, 40-41, 45-46, 48, 50-54, 57, 60-61, 63-64, 67, 69-2, 70, 72-73, 74, 75-3 The following items are conditionally closed: 11, 12, 14, 17, 24, 26, 28, 35, 39, 42-44, 47, 49, 55-56, 58-59, 62, 65-66, 68, 69-1, 71, 75-1,75-2, 75-4, N+1,N+2, N+3 WooHoo! The specified changes have been made to the draft. We'll check it over a few more times, and will submit it before the end of the day. Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Monday, November 17, 2003 8:57 AM To: Disman (E-mail) Subject: RE: [Disman] Closed item from Randy's Review Hi Current Score: The following items are closed: 1-10, 13, 15-23, 25, 27, 29-34, 36-38, 40-41, 45-46, 48, 50-54, 57, 60-61, 64, 67, 69-2, 70, 72-73, 74, 75-3 The following items are conditionally closed: 11, 12, 14, 17, 24, 26, 28, 35, 39, 42-44, 47, 49, 55-56, 58-59, 62-63, 65-66, 68, 71, 75-1,75-2, N+1,N+2, N+3 The following items are still be processed: 65, 69-1, 75-4 Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Sunday, November 02, 2003 5:29 AM To: Disman (E-mail) Subject: RE: [Disman] Closed item from Randy's Review Hi Current Score: The following items are closed: 1-10, 13, 15-23, 25, 27, 29-34, 36-38, 40-41, 45-46, 48, 50-54, 57, 60-61, 64, 67, 69-2, 70, 72-73, 74, 75-3 The following items are conditionally closed: 11, 12, 14, 17, 24, 28, 35, 42-44, 49, 56, 58, 62-63, 65-66, 71, 75-1, N+1,N+2, N+3 The following items are still be processed: 26, 39, 47, 55, 59, 65, 68, 69-1, 75-2, 75-4 Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, October 15, 2003 12:37 PM To: Disman (E-mail) Subject: RE: [Disman] Closed item from Randy's Review Hi For those keeping score at home, this is where we stand: The following items are closed: 1-10, 13, 15-23, 25, 27, 29-34, 36-38, 40-41, 45-46, 48, 50-54, 57, 61, 64, 67, 69-2, 70, 72-73, 74, 75-3 The following items are conditionally closed: 11, 12, 14, 17, 35, 42-43, 49, 62-63, 65-66, 71, N+1 The following items are still be processed: 24, 26, 28, 39, 44, 47, 55-56, 58-60, 65, 68, 69-1, 75-1. 75-2, 75-4, N+2, N+3 Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Tuesday, October 07, 2003 1:46 PM To: Disman (E-mail) Cc: Randy Presuhn Subject: RE: [Disman] Closed item from Randy's Review Hi As I said, the email was to ensure we were all on the same page. It is not in anybody's best interest for a -16 to be created and then have these issues brought up again. When can we expect a thumbs up/down on the remaining items? Any items not in this list will be handled separately. I want the remaining items conditionally closed before issuing -16. As in, if text X is replaced with text Y then this issue is closed. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 07, 2003 1:32 PM To: Disman (E-mail) Subject: Re: [Disman] Closed item from Randy's Review Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Tuesday, October 07, 2003 9:40 AM > Subject: [Disman] Closed item from Randy's Review ... > Just to ensure we are on the same page: Having received no indication > that the update -15 or the explanation for not making an update did > not satisfy the issue, the follow issues are considered closed: > > 1, 3-10, 13, 15-25, 27-32, 34, 36-41, 45-46, 48, 50-54, 56-57, 60-61, > 64, 67-69, 73, 74-1, 74-2, 74-4, 75-1 ... Not so fast. Numbers 24, 28, 39, 56, 60, 75-1, 68, and 69-1 I still need to check, so I object to considering them closed until I've had an opportunity to do so. I assume this means you agree to fix #17. I strongly RECOMMEND fixing 7, 13, 15a, and 16. Randy (as technical contributor) From exim@www1.ietf.org Wed Nov 19 10:17:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21314 for ; Wed, 19 Nov 2003 10:17:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMU4p-0000fC-P3 for disman-archive@odin.ietf.org; Wed, 19 Nov 2003 10:17:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJFH7Wh002546 for disman-archive@odin.ietf.org; Wed, 19 Nov 2003 10:17:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMU4p-0000ez-M9 for disman-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 10:17:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21256 for ; Wed, 19 Nov 2003 10:16:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMU4n-0000xE-00 for disman-web-archive@ietf.org; Wed, 19 Nov 2003 10:17:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMU4n-0000xA-00 for disman-web-archive@ietf.org; Wed, 19 Nov 2003 10:17:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMU4i-0000eS-VQ; Wed, 19 Nov 2003 10:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMU4S-0000eB-KW for disman@optimus.ietf.org; Wed, 19 Nov 2003 10:16:44 -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 KAA21204 for ; Wed, 19 Nov 2003 10:16:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMU4Q-0000x0-00 for disman@ietf.org; Wed, 19 Nov 2003 10:16:42 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AMU4P-0000u8-00 for disman@ietf.org; Wed, 19 Nov 2003 10:16:41 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAJFGA522903 for ; Wed, 19 Nov 2003 10:16:10 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Nov 2003 10:16:10 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34094E446E@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Closed item from Randy's Review 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, 19 Nov 2003 10:16:08 -0500 Hi Current Score: The following items are closed: 1-10, 13, 15-23, 25, 27, 29-34, 36-38, 40-41, 45-46, 48, 50-54, 57, 60-61, 63-64, 67, 69-2, 70, 72-73, 74, 75-3 The following items are conditionally closed: 11, 12, 14, 17, 24, 26, 28, 35, 39, 42-44, 47, 49, 55-56, 58-59, 62, 65-66, 68, 69-1, 71, 75-1,75-2, 75-4, N+1,N+2, N+3 WooHoo! The specified changes have been made to the draft. We'll check it over a few more times, and will submit it before the end of the day. Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Monday, November 17, 2003 8:57 AM To: Disman (E-mail) Subject: RE: [Disman] Closed item from Randy's Review Hi Current Score: The following items are closed: 1-10, 13, 15-23, 25, 27, 29-34, 36-38, 40-41, 45-46, 48, 50-54, 57, 60-61, 64, 67, 69-2, 70, 72-73, 74, 75-3 The following items are conditionally closed: 11, 12, 14, 17, 24, 26, 28, 35, 39, 42-44, 47, 49, 55-56, 58-59, 62-63, 65-66, 68, 71, 75-1,75-2, N+1,N+2, N+3 The following items are still be processed: 65, 69-1, 75-4 Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Sunday, November 02, 2003 5:29 AM To: Disman (E-mail) Subject: RE: [Disman] Closed item from Randy's Review Hi Current Score: The following items are closed: 1-10, 13, 15-23, 25, 27, 29-34, 36-38, 40-41, 45-46, 48, 50-54, 57, 60-61, 64, 67, 69-2, 70, 72-73, 74, 75-3 The following items are conditionally closed: 11, 12, 14, 17, 24, 28, 35, 42-44, 49, 56, 58, 62-63, 65-66, 71, 75-1, N+1,N+2, N+3 The following items are still be processed: 26, 39, 47, 55, 59, 65, 68, 69-1, 75-2, 75-4 Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, October 15, 2003 12:37 PM To: Disman (E-mail) Subject: RE: [Disman] Closed item from Randy's Review Hi For those keeping score at home, this is where we stand: The following items are closed: 1-10, 13, 15-23, 25, 27, 29-34, 36-38, 40-41, 45-46, 48, 50-54, 57, 61, 64, 67, 69-2, 70, 72-73, 74, 75-3 The following items are conditionally closed: 11, 12, 14, 17, 35, 42-43, 49, 62-63, 65-66, 71, N+1 The following items are still be processed: 24, 26, 28, 39, 44, 47, 55-56, 58-60, 65, 68, 69-1, 75-1. 75-2, 75-4, N+2, N+3 Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Tuesday, October 07, 2003 1:46 PM To: Disman (E-mail) Cc: Randy Presuhn Subject: RE: [Disman] Closed item from Randy's Review Hi As I said, the email was to ensure we were all on the same page. It is not in anybody's best interest for a -16 to be created and then have these issues brought up again. When can we expect a thumbs up/down on the remaining items? Any items not in this list will be handled separately. I want the remaining items conditionally closed before issuing -16. As in, if text X is replaced with text Y then this issue is closed. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 07, 2003 1:32 PM To: Disman (E-mail) Subject: Re: [Disman] Closed item from Randy's Review Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Tuesday, October 07, 2003 9:40 AM > Subject: [Disman] Closed item from Randy's Review ... > Just to ensure we are on the same page: Having received no indication > that the update -15 or the explanation for not making an update did > not satisfy the issue, the follow issues are considered closed: > > 1, 3-10, 13, 15-25, 27-32, 34, 36-41, 45-46, 48, 50-54, 56-57, 60-61, > 64, 67-69, 73, 74-1, 74-2, 74-4, 75-1 ... Not so fast. Numbers 24, 28, 39, 56, 60, 75-1, 68, and 69-1 I still need to check, so I object to considering them closed until I've had an opportunity to do so. I assume this means you agree to fix #17. I strongly RECOMMEND fixing 7, 13, 15a, and 16. Randy (as technical contributor) From disman-admin@ietf.org Thu Nov 20 14:09:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19131 for ; Thu, 20 Nov 2003 14:09:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuAn-0002CS-C1; Thu, 20 Nov 2003 14: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 1AMuAY-0002B6-9z for disman@optimus.ietf.org; Thu, 20 Nov 2003 14:08:46 -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 OAA19061 for ; Thu, 20 Nov 2003 14:08:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMuAV-0000Y0-00 for disman@ietf.org; Thu, 20 Nov 2003 14:08:43 -0500 Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by ietf-mx with esmtp (Exim 4.12) id 1AMuAV-0000Xw-00 for disman@ietf.org; Thu, 20 Nov 2003 14:08:43 -0500 Received: from h-68-164-78-60.snvacaid.dynamic.covad.net ([68.164.78.60] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AMuAE-0003h5-00; Thu, 20 Nov 2003 11:08:26 -0800 Message-ID: <00f801c3af99$ebd0e9a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Wijnen, Bert \(Bert\)" , "Tom Petch" Cc: , "Disman \(E-mail\)" References: <7D5D48D2CAA3D84C813F5B154F43B15502FB8068@nl0006exch001u.nl.lucent.com> 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] Re: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 11:10:10 -0800 Hi - > From: "Wijnen, Bert (Bert)" > To: "Tom Petch" ; "Wijnen, Bert (Bert)" > Cc: ; "Randy Presuhn" > Sent: Wednesday, November 19, 2003 7:59 AM > Subject: RE: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > I believe thatthe codepoints we are talking about are not > under discussion. Add those are in a TC that is in a > separate MIB module in that document and the intent is > that IANA (see start of module on page 36) will maintain > that module and keep it in sync with ITU-T (in fact values under > 1024 are reserved for ITU-T). > > Hope this clarifies. ... Bert's summary is correct. Disman is wrapping up the discussion of the review comments on draft-ietf-disman-alarm-mib-15.txt, and has made no structural changes. There have been a lot of clarifications and some minor tweaks, such as handling of out-of-memory conditions, but nothing drastic. I think it would be very interesting to describe how alarm information communicated using the mechanisms described in http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-00.txt would be represented in the alarm MIB. However, I do not think that it would make sense to wait for such an analysis to be completed before handing the alarm MIB to the IESG, particularly since the alarm report control document is in the RFC editor queue at this time. Comments on possible mappings between the ccamp alarms and the alarm MIB would be welcome on the disman@ietf.org mailing list, and would be taken into account when the time comes to revisit the alarm MIB, or, if there is sufficient need and support, as an extension model. Of course, actually chartering such work would be up to the AD. Randy Presuhn disman WG chair From exim@www1.ietf.org Thu Nov 20 14:09:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19146 for ; Thu, 20 Nov 2003 14:09:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuAs-0002DT-Fm for disman-archive@odin.ietf.org; Thu, 20 Nov 2003 14:09:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKJ960v008513 for disman-archive@odin.ietf.org; Thu, 20 Nov 2003 14:09:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuAs-0002DE-CF for disman-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 14:09:06 -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 OAA19110 for ; Thu, 20 Nov 2003 14:08:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMuAp-0000Yf-00 for disman-web-archive@ietf.org; Thu, 20 Nov 2003 14:09:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMuAp-0000Ya-00 for disman-web-archive@ietf.org; Thu, 20 Nov 2003 14:09:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuAn-0002CS-C1; Thu, 20 Nov 2003 14: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 1AMuAY-0002B6-9z for disman@optimus.ietf.org; Thu, 20 Nov 2003 14:08:46 -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 OAA19061 for ; Thu, 20 Nov 2003 14:08:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMuAV-0000Y0-00 for disman@ietf.org; Thu, 20 Nov 2003 14:08:43 -0500 Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by ietf-mx with esmtp (Exim 4.12) id 1AMuAV-0000Xw-00 for disman@ietf.org; Thu, 20 Nov 2003 14:08:43 -0500 Received: from h-68-164-78-60.snvacaid.dynamic.covad.net ([68.164.78.60] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AMuAE-0003h5-00; Thu, 20 Nov 2003 11:08:26 -0800 Message-ID: <00f801c3af99$ebd0e9a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Wijnen, Bert \(Bert\)" , "Tom Petch" Cc: , "Disman \(E-mail\)" References: <7D5D48D2CAA3D84C813F5B154F43B15502FB8068@nl0006exch001u.nl.lucent.com> 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] Re: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 11:10:10 -0800 Hi - > From: "Wijnen, Bert (Bert)" > To: "Tom Petch" ; "Wijnen, Bert (Bert)" > Cc: ; "Randy Presuhn" > Sent: Wednesday, November 19, 2003 7:59 AM > Subject: RE: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > I believe thatthe codepoints we are talking about are not > under discussion. Add those are in a TC that is in a > separate MIB module in that document and the intent is > that IANA (see start of module on page 36) will maintain > that module and keep it in sync with ITU-T (in fact values under > 1024 are reserved for ITU-T). > > Hope this clarifies. ... Bert's summary is correct. Disman is wrapping up the discussion of the review comments on draft-ietf-disman-alarm-mib-15.txt, and has made no structural changes. There have been a lot of clarifications and some minor tweaks, such as handling of out-of-memory conditions, but nothing drastic. I think it would be very interesting to describe how alarm information communicated using the mechanisms described in http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-00.txt would be represented in the alarm MIB. However, I do not think that it would make sense to wait for such an analysis to be completed before handing the alarm MIB to the IESG, particularly since the alarm report control document is in the RFC editor queue at this time. Comments on possible mappings between the ccamp alarms and the alarm MIB would be welcome on the disman@ietf.org mailing list, and would be taken into account when the time comes to revisit the alarm MIB, or, if there is sufficient need and support, as an extension model. Of course, actually chartering such work would be up to the AD. Randy Presuhn disman WG chair From disman-admin@ietf.org Fri Nov 21 16:03:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02319 for ; Fri, 21 Nov 2003 16:03:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANIQf-00036b-BN; Fri, 21 Nov 2003 16:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANIQJ-00036N-1B for disman@optimus.ietf.org; Fri, 21 Nov 2003 16:02:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02214; Fri, 21 Nov 2003 16:02:25 -0500 (EST) Message-Id: <200311212102.QAA02214@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-alarm-mib-16.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Nov 2003 16:02:25 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Alarm MIB Author(s) : S. Chisholm, D. Romascanu Filename : draft-ietf-disman-alarm-mib-16.txt Pages : 70 Date : 2003-11-21 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for defining and storing alarms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-16.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-alarm-mib-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-alarm-mib-16.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-21161929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-alarm-mib-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-alarm-mib-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-21161929.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Fri Nov 21 16:03:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02334 for ; Fri, 21 Nov 2003 16:03:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANIQm-00038r-Nv for disman-archive@odin.ietf.org; Fri, 21 Nov 2003 16:03:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALL38Ud012076 for disman-archive@odin.ietf.org; Fri, 21 Nov 2003 16:03:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANIQm-00038h-K0 for disman-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 16:03:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02278 for ; Fri, 21 Nov 2003 16:02:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANIQk-0000jm-00 for disman-web-archive@ietf.org; Fri, 21 Nov 2003 16:03:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANIQk-0000ji-00 for disman-web-archive@ietf.org; Fri, 21 Nov 2003 16:03:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANIQf-00036b-BN; Fri, 21 Nov 2003 16:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANIQJ-00036N-1B for disman@optimus.ietf.org; Fri, 21 Nov 2003 16:02:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02214; Fri, 21 Nov 2003 16:02:25 -0500 (EST) Message-Id: <200311212102.QAA02214@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-alarm-mib-16.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Nov 2003 16:02:25 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Alarm MIB Author(s) : S. Chisholm, D. Romascanu Filename : draft-ietf-disman-alarm-mib-16.txt Pages : 70 Date : 2003-11-21 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for defining and storing alarms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-16.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-alarm-mib-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-alarm-mib-16.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-21161929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-alarm-mib-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-alarm-mib-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-21161929.I-D@ietf.org> --OtherAccess-- --NextPart--