From disman-admin@ietf.org Wed Oct 1 04:48: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 EAA03470 for ; Wed, 1 Oct 2003 04:48:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ceO-0001gl-Sk; Wed, 01 Oct 2003 04:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4cdb-0001dl-4M for disman@optimus.ietf.org; Wed, 01 Oct 2003 04:47:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03405 for ; Wed, 1 Oct 2003 04:47:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4cdY-00046h-00 for disman@ietf.org; Wed, 01 Oct 2003 04:47:08 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A4cdX-00046X-00 for disman@ietf.org; Wed, 01 Oct 2003 04:47:07 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h918kZU02558 for ; Wed, 1 Oct 2003 03:46:35 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Wed, 1 Oct 2003 10:46:33 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC3B0@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Disman (E-mail) (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: [Disman] FW: draft-ietf-disman-conditionmib 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, 1 Oct 2003 10:46:26 +0200 FYI Thanks, Bert -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: woensdag 1 oktober 2003 10:37 To: 'Russ Housley'; iesg@ietf.org Subject: RE: draft-ietf-disman-conditionmib Russ writes: > > The ability to remotely shut off alarms seems to have a slightly different > security consideration that the usual MIB document, yet this document has > the typical boilerplate. But... it is not JUST Boilerplate !!! I did (and normally always do) ask them to be specific and explain what the vulnerabilities are and I think they did. They have in the security section: network operations. These are the tables and objects and their sensitivity/vulnerability: arcTITimeInterval, arcCDTimeInterval, arcState, arcNalmTimeRemaining, arcRowStatus, arcStorageType. 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 netowrk. Maybe you do not find that detailed/speciifc enough? But I am not sure we want them to go into detail about specific alarms, cause this table is a generic table. > I do not feel strong enough to register a DISCUSS, but there is > something unsettling. Part of the reason that I do not > want to register a DISCUSS is because the alarms themselves are not > described in this document. The context of the alarms needs to be > understood to determine the security consequences of masking them. > Well... they reference the ITU documents where these ARE described. We do not want them to repat that description, do we? Hope this makes you feel better letting it pass. Bert > Russ > > From exim@www1.ietf.org Wed Oct 1 04:48:28 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 EAA03487 for ; Wed, 1 Oct 2003 04:48:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ceT-0001i8-Gk for disman-archive@odin.ietf.org; Wed, 01 Oct 2003 04:48:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h918m5TJ006547 for disman-archive@odin.ietf.org; Wed, 1 Oct 2003 04:48:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ceT-0001hQ-5E for disman-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 04:48:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03435 for ; Wed, 1 Oct 2003 04:47:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ceP-00047V-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 04:48:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4ceP-00047R-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 04:48:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ceO-0001gl-Sk; Wed, 01 Oct 2003 04:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4cdb-0001dl-4M for disman@optimus.ietf.org; Wed, 01 Oct 2003 04:47:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03405 for ; Wed, 1 Oct 2003 04:47:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4cdY-00046h-00 for disman@ietf.org; Wed, 01 Oct 2003 04:47:08 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A4cdX-00046X-00 for disman@ietf.org; Wed, 01 Oct 2003 04:47:07 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h918kZU02558 for ; Wed, 1 Oct 2003 03:46:35 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Wed, 1 Oct 2003 10:46:33 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC3B0@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Disman (E-mail) (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: [Disman] FW: draft-ietf-disman-conditionmib 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, 1 Oct 2003 10:46:26 +0200 FYI Thanks, Bert -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: woensdag 1 oktober 2003 10:37 To: 'Russ Housley'; iesg@ietf.org Subject: RE: draft-ietf-disman-conditionmib Russ writes: > > The ability to remotely shut off alarms seems to have a slightly different > security consideration that the usual MIB document, yet this document has > the typical boilerplate. But... it is not JUST Boilerplate !!! I did (and normally always do) ask them to be specific and explain what the vulnerabilities are and I think they did. They have in the security section: network operations. These are the tables and objects and their sensitivity/vulnerability: arcTITimeInterval, arcCDTimeInterval, arcState, arcNalmTimeRemaining, arcRowStatus, arcStorageType. 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 netowrk. Maybe you do not find that detailed/speciifc enough? But I am not sure we want them to go into detail about specific alarms, cause this table is a generic table. > I do not feel strong enough to register a DISCUSS, but there is > something unsettling. Part of the reason that I do not > want to register a DISCUSS is because the alarms themselves are not > described in this document. The context of the alarms needs to be > understood to determine the security consequences of masking them. > Well... they reference the ITU documents where these ARE described. We do not want them to repat that description, do we? Hope this makes you feel better letting it pass. Bert > Russ > > From disman-admin@ietf.org Wed Oct 1 10:11: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 KAA14044 for ; Wed, 1 Oct 2003 10:11:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4hgz-0002Td-SJ; Wed, 01 Oct 2003 10:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4hgL-0002Sl-HS for disman@optimus.ietf.org; Wed, 01 Oct 2003 10:10:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13918 for ; Wed, 1 Oct 2003 10:10:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4hgJ-0007Qf-00 for disman@ietf.org; Wed, 01 Oct 2003 10:10:19 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A4hgI-0007Qb-00 for disman@ietf.org; Wed, 01 Oct 2003 10:10:18 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h91EAPC01364 for ; Wed, 1 Oct 2003 09:10:27 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Wed, 1 Oct 2003 16:09:43 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC3C2@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Disman (E-mail) (E-mail)" Subject: RE: [Disman] FW: draft-ietf-disman-conditionmib MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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, 1 Oct 2003 16:09:42 +0200 In further discussions between Russ and me, the proposal now is to replace this text on page 13: 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 netowrk. with this 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. Any objection fropm author/editor and or WG members? We can make the change via an RFC-Editor note, so no need to respin the doc. Thanks, Bert > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: woensdag 1 oktober 2003 10:46 > To: Disman (E-mail) (E-mail) > Subject: [Disman] FW: draft-ietf-disman-conditionmib > > > FYI > > Thanks, > Bert > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: woensdag 1 oktober 2003 10:37 > To: 'Russ Housley'; iesg@ietf.org > Subject: RE: draft-ietf-disman-conditionmib > > > Russ writes: > > > > The ability to remotely shut off alarms seems to have a > slightly different > > security consideration that the usual MIB document, yet > this document has > > the typical boilerplate. > > But... it is not JUST Boilerplate !!! > I did (and normally always do) ask them to be specific and explain > what the vulnerabilities are and I think they did. They have in the > security section: > > network operations. These are the tables and objects and their > sensitivity/vulnerability: > > arcTITimeInterval, > arcCDTimeInterval, > arcState, > arcNalmTimeRemaining, > arcRowStatus, > arcStorageType. > > 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 netowrk. > > Maybe you do not find that detailed/speciifc enough? > But I am not sure we want them to go into detail about specific > alarms, cause this table is a generic table. > > > I do not feel strong enough to register a DISCUSS, but there is > > something unsettling. Part of the reason that I do not > > want to register a DISCUSS is because the alarms themselves are not > > described in this document. The context of the alarms needs to be > > understood to determine the security consequences of masking them. > > > Well... they reference the ITU documents where these ARE described. > We do not want them to repat that description, do we? > > Hope this makes you feel better letting it pass. > > Bert > > Russ > > > > > From exim@www1.ietf.org Wed Oct 1 10:11:29 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 KAA14062 for ; Wed, 1 Oct 2003 10:11:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4hh4-0002UP-2t for disman-archive@odin.ietf.org; Wed, 01 Oct 2003 10:11:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91EB6AZ009563 for disman-archive@odin.ietf.org; Wed, 1 Oct 2003 10:11:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4hh3-0002UA-UF for disman-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 10:11:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13991 for ; Wed, 1 Oct 2003 10:10:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4hh1-0007R6-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 10:11:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4hh1-0007R3-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 10:11:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4hgz-0002Td-SJ; Wed, 01 Oct 2003 10:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4hgL-0002Sl-HS for disman@optimus.ietf.org; Wed, 01 Oct 2003 10:10:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13918 for ; Wed, 1 Oct 2003 10:10:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4hgJ-0007Qf-00 for disman@ietf.org; Wed, 01 Oct 2003 10:10:19 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A4hgI-0007Qb-00 for disman@ietf.org; Wed, 01 Oct 2003 10:10:18 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h91EAPC01364 for ; Wed, 1 Oct 2003 09:10:27 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Wed, 1 Oct 2003 16:09:43 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC3C2@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Disman (E-mail) (E-mail)" Subject: RE: [Disman] FW: draft-ietf-disman-conditionmib MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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, 1 Oct 2003 16:09:42 +0200 In further discussions between Russ and me, the proposal now is to replace this text on page 13: 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 netowrk. with this 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. Any objection fropm author/editor and or WG members? We can make the change via an RFC-Editor note, so no need to respin the doc. Thanks, Bert > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: woensdag 1 oktober 2003 10:46 > To: Disman (E-mail) (E-mail) > Subject: [Disman] FW: draft-ietf-disman-conditionmib > > > FYI > > Thanks, > Bert > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: woensdag 1 oktober 2003 10:37 > To: 'Russ Housley'; iesg@ietf.org > Subject: RE: draft-ietf-disman-conditionmib > > > Russ writes: > > > > The ability to remotely shut off alarms seems to have a > slightly different > > security consideration that the usual MIB document, yet > this document has > > the typical boilerplate. > > But... it is not JUST Boilerplate !!! > I did (and normally always do) ask them to be specific and explain > what the vulnerabilities are and I think they did. They have in the > security section: > > network operations. These are the tables and objects and their > sensitivity/vulnerability: > > arcTITimeInterval, > arcCDTimeInterval, > arcState, > arcNalmTimeRemaining, > arcRowStatus, > arcStorageType. > > 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 netowrk. > > Maybe you do not find that detailed/speciifc enough? > But I am not sure we want them to go into detail about specific > alarms, cause this table is a generic table. > > > I do not feel strong enough to register a DISCUSS, but there is > > something unsettling. Part of the reason that I do not > > want to register a DISCUSS is because the alarms themselves are not > > described in this document. The context of the alarms needs to be > > understood to determine the security consequences of masking them. > > > Well... they reference the ITU documents where these ARE described. > We do not want them to repat that description, do we? > > Hope this makes you feel better letting it pass. > > Bert > > Russ > > > > > From disman-admin@ietf.org Wed Oct 1 10:35: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 KAA15504 for ; Wed, 1 Oct 2003 10:35:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4i4E-0003uJ-RG; Wed, 01 Oct 2003 10:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4i3i-0003nI-H0 for disman@optimus.ietf.org; Wed, 01 Oct 2003 10:34:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15410 for ; Wed, 1 Oct 2003 10:34:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4i3T-0007gt-00 for disman@ietf.org; Wed, 01 Oct 2003 10:34:15 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A4i3T-0007gM-00 for disman@ietf.org; Wed, 01 Oct 2003 10:34:15 -0400 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h91EXgt27227 for ; Wed, 1 Oct 2003 09:33:42 -0500 (CDT) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id ; Wed, 1 Oct 2003 10:33:41 -0400 Message-ID: From: "Lam, Hing-Kam (Kam)" To: "Wijnen, Bert (Bert)" , "Disman (E-mail) (E-mail)" Subject: RE: [Disman] FW: draft-ietf-disman-conditionmib MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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, 1 Oct 2003 10:33:40 -0400 The replacement text is fine to me. Thanks. Regards, Kam > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Wednesday, October 01, 2003 10:10 AM > To: Disman (E-mail) (E-mail) > Subject: RE: [Disman] FW: draft-ietf-disman-conditionmib > > > In further discussions between Russ and me, the proposal now > is to replace this text on page 13: > > 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 netowrk. > > with this 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. > > Any objection fropm author/editor and or WG members? > > We can make the change via an RFC-Editor note, so no need > to respin the doc. > > Thanks, > Bert > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: woensdag 1 oktober 2003 10:46 > > To: Disman (E-mail) (E-mail) > > Subject: [Disman] FW: draft-ietf-disman-conditionmib > > > > > > FYI > > > > Thanks, > > Bert > > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: woensdag 1 oktober 2003 10:37 > > To: 'Russ Housley'; iesg@ietf.org > > Subject: RE: draft-ietf-disman-conditionmib > > > > > > Russ writes: > > > > > > The ability to remotely shut off alarms seems to have a > > slightly different > > > security consideration that the usual MIB document, yet > > this document has > > > the typical boilerplate. > > > > But... it is not JUST Boilerplate !!! > > I did (and normally always do) ask them to be specific and explain > > what the vulnerabilities are and I think they did. They have in the > > security section: > > > > network operations. These are the tables and objects and their > > sensitivity/vulnerability: > > > > arcTITimeInterval, > > arcCDTimeInterval, > > arcState, > > arcNalmTimeRemaining, > > arcRowStatus, > > arcStorageType. > > > > 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 netowrk. > > > > Maybe you do not find that detailed/speciifc enough? > > But I am not sure we want them to go into detail about specific > > alarms, cause this table is a generic table. > > > > > I do not feel strong enough to register a DISCUSS, but there is > > > something unsettling. Part of the reason that I do not > > > want to register a DISCUSS is because the alarms > themselves are not > > > described in this document. The context of the alarms > needs to be > > > understood to determine the security consequences of masking them. > > > > > Well... they reference the ITU documents where these ARE described. > > We do not want them to repat that description, do we? > > > > Hope this makes you feel better letting it pass. > > > > Bert > > > Russ > > > > > > > > > From exim@www1.ietf.org Wed Oct 1 10:35: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 KAA15521 for ; Wed, 1 Oct 2003 10:35:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4i4G-0003v0-Ng for disman-archive@odin.ietf.org; Wed, 01 Oct 2003 10:35:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91EZ4U4015061 for disman-archive@odin.ietf.org; Wed, 1 Oct 2003 10:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4i4G-0003uq-Ka for disman-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 10:35:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15456 for ; Wed, 1 Oct 2003 10:34:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4i4E-0007hW-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 10:35:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4i4D-0007hT-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 10:35:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4i4E-0003uJ-RG; Wed, 01 Oct 2003 10:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4i3i-0003nI-H0 for disman@optimus.ietf.org; Wed, 01 Oct 2003 10:34:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15410 for ; Wed, 1 Oct 2003 10:34:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4i3T-0007gt-00 for disman@ietf.org; Wed, 01 Oct 2003 10:34:15 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A4i3T-0007gM-00 for disman@ietf.org; Wed, 01 Oct 2003 10:34:15 -0400 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h91EXgt27227 for ; Wed, 1 Oct 2003 09:33:42 -0500 (CDT) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id ; Wed, 1 Oct 2003 10:33:41 -0400 Message-ID: From: "Lam, Hing-Kam (Kam)" To: "Wijnen, Bert (Bert)" , "Disman (E-mail) (E-mail)" Subject: RE: [Disman] FW: draft-ietf-disman-conditionmib MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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, 1 Oct 2003 10:33:40 -0400 The replacement text is fine to me. Thanks. Regards, Kam > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Wednesday, October 01, 2003 10:10 AM > To: Disman (E-mail) (E-mail) > Subject: RE: [Disman] FW: draft-ietf-disman-conditionmib > > > In further discussions between Russ and me, the proposal now > is to replace this text on page 13: > > 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 netowrk. > > with this 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. > > Any objection fropm author/editor and or WG members? > > We can make the change via an RFC-Editor note, so no need > to respin the doc. > > Thanks, > Bert > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: woensdag 1 oktober 2003 10:46 > > To: Disman (E-mail) (E-mail) > > Subject: [Disman] FW: draft-ietf-disman-conditionmib > > > > > > FYI > > > > Thanks, > > Bert > > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: woensdag 1 oktober 2003 10:37 > > To: 'Russ Housley'; iesg@ietf.org > > Subject: RE: draft-ietf-disman-conditionmib > > > > > > Russ writes: > > > > > > The ability to remotely shut off alarms seems to have a > > slightly different > > > security consideration that the usual MIB document, yet > > this document has > > > the typical boilerplate. > > > > But... it is not JUST Boilerplate !!! > > I did (and normally always do) ask them to be specific and explain > > what the vulnerabilities are and I think they did. They have in the > > security section: > > > > network operations. These are the tables and objects and their > > sensitivity/vulnerability: > > > > arcTITimeInterval, > > arcCDTimeInterval, > > arcState, > > arcNalmTimeRemaining, > > arcRowStatus, > > arcStorageType. > > > > 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 netowrk. > > > > Maybe you do not find that detailed/speciifc enough? > > But I am not sure we want them to go into detail about specific > > alarms, cause this table is a generic table. > > > > > I do not feel strong enough to register a DISCUSS, but there is > > > something unsettling. Part of the reason that I do not > > > want to register a DISCUSS is because the alarms > themselves are not > > > described in this document. The context of the alarms > needs to be > > > understood to determine the security consequences of masking them. > > > > > Well... they reference the ITU documents where these ARE described. > > We do not want them to repat that description, do we? > > > > Hope this makes you feel better letting it pass. > > > > Bert > > > Russ > > > > > > > > > From disman-admin@ietf.org Wed Oct 1 10:58: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 KAA16626 for ; Wed, 1 Oct 2003 10:58:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4iQT-0005G0-0e; Wed, 01 Oct 2003 10:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4iQN-0005Ef-1d for disman@optimus.ietf.org; Wed, 01 Oct 2003 10:57:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16496; Wed, 1 Oct 2003 10:57:46 -0400 (EDT) Message-Id: <200310011457.KAA16496@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-15.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 01 Oct 2003 10:57:46 -0400 --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-15.txt Pages : 67 Date : 2003-10-1 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-15.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-15.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-15.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-10-1103300.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-alarm-mib-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-alarm-mib-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-1103300.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Wed Oct 1 10:58:24 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 KAA16647 for ; Wed, 1 Oct 2003 10:58:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4iQU-0005Go-9B for disman-archive@odin.ietf.org; Wed, 01 Oct 2003 10:58:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91Ew2TM020252 for disman-archive@odin.ietf.org; Wed, 1 Oct 2003 10:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4iQU-0005GZ-50 for disman-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 10:58:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16527 for ; Wed, 1 Oct 2003 10:57:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4iQR-0000EB-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 10:57:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4iQR-0000E8-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 10:57:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4iQT-0005G0-0e; Wed, 01 Oct 2003 10:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4iQN-0005Ef-1d for disman@optimus.ietf.org; Wed, 01 Oct 2003 10:57:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16496; Wed, 1 Oct 2003 10:57:46 -0400 (EDT) Message-Id: <200310011457.KAA16496@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-15.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 01 Oct 2003 10:57:46 -0400 --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-15.txt Pages : 67 Date : 2003-10-1 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-15.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-15.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-15.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-10-1103300.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-alarm-mib-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-alarm-mib-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-1103300.I-D@ietf.org> --OtherAccess-- --NextPart-- From disman-admin@ietf.org Wed Oct 1 13:01:28 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 NAA23602 for ; Wed, 1 Oct 2003 13:01:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kLW-0005v6-8A; Wed, 01 Oct 2003 13:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kKn-0005ol-EG for disman@optimus.ietf.org; Wed, 01 Oct 2003 13:00:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23527 for ; Wed, 1 Oct 2003 13:00:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4kKl-0002Bg-00 for disman@ietf.org; Wed, 01 Oct 2003 13:00:15 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A4kKl-0002AG-00 for disman@ietf.org; Wed, 01 Oct 2003 13:00:15 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h91GwU022128 for ; Wed, 1 Oct 2003 12:58:31 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Oct 2003 12:58:31 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408BC0DF1@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm MIB Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 1 Oct 2003 12:58:31 -0400 Hi I took an action out of IETF 56 to draft a response to the liaison from ITU-T Study Group 4 on Alarm MIB. As the next SG 4 meeting starts on October 27th, I figured I should finally take a crack at that. We agreed on the spirit of this text when we last met as a working group. Here goes: "Thank you for the interest in the Alarm MIB. The Distributed Management (disman) working group hopes to advance the current I-D to Proposed Standard, with minimal editorial changes. In the future, if the working group is chartered with an Alarm MIB version 2, we will be interested in cooperating with you to ensure your requirements are considered." When we agree on the text, did you want me to get it to SG 4 or did we want to follow another path? Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From exim@www1.ietf.org Wed Oct 1 13:01:29 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 NAA23617 for ; Wed, 1 Oct 2003 13:01:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kLb-0005wi-4n for disman-archive@odin.ietf.org; Wed, 01 Oct 2003 13:01:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91H17CJ022853 for disman-archive@odin.ietf.org; Wed, 1 Oct 2003 13:01:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kLa-0005wW-UN for disman-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 13:01:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23572 for ; Wed, 1 Oct 2003 13:00:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4kLZ-0002Ck-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 13:01:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4kLY-0002Ch-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 13:01:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kLW-0005v6-8A; Wed, 01 Oct 2003 13:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kKn-0005ol-EG for disman@optimus.ietf.org; Wed, 01 Oct 2003 13:00:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23527 for ; Wed, 1 Oct 2003 13:00:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4kKl-0002Bg-00 for disman@ietf.org; Wed, 01 Oct 2003 13:00:15 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A4kKl-0002AG-00 for disman@ietf.org; Wed, 01 Oct 2003 13:00:15 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h91GwU022128 for ; Wed, 1 Oct 2003 12:58:31 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Oct 2003 12:58:31 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408BC0DF1@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm MIB Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 1 Oct 2003 12:58:31 -0400 Hi I took an action out of IETF 56 to draft a response to the liaison from ITU-T Study Group 4 on Alarm MIB. As the next SG 4 meeting starts on October 27th, I figured I should finally take a crack at that. We agreed on the spirit of this text when we last met as a working group. Here goes: "Thank you for the interest in the Alarm MIB. The Distributed Management (disman) working group hopes to advance the current I-D to Proposed Standard, with minimal editorial changes. In the future, if the working group is chartered with an Alarm MIB version 2, we will be interested in cooperating with you to ensure your requirements are considered." When we agree on the text, did you want me to get it to SG 4 or did we want to follow another path? Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From disman-admin@ietf.org Wed Oct 1 16:24:32 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 QAA02729 for ; Wed, 1 Oct 2003 16:24:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4nVy-00008C-3I; Wed, 01 Oct 2003 16:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4nVw-000080-R0 for disman@optimus.ietf.org; Wed, 01 Oct 2003 16:24:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02712 for ; Wed, 1 Oct 2003 16:23:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4nVu-0004jJ-00 for disman@ietf.org; Wed, 01 Oct 2003 16:23:58 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4nVu-0004jG-00 for disman@ietf.org; Wed, 01 Oct 2003 16:23:58 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4nVp-000758-00 for disman@ietf.org; Wed, 01 Oct 2003 13:23:53 -0700 Message-ID: <000801c38859$cc106800$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408BC0DF1@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm MIB X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 1 Oct 2003 13:22:54 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Wednesday, October 01, 2003 9:58 AM > Subject: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm MIB ... > I took an action out of IETF 56 to draft a response to the liaison from > ITU-T Study Group 4 on Alarm MIB. As the next SG 4 meeting starts on October > 27th, I figured I should finally take a crack at that. We agreed on the > spirit of this text when we last met as a working group. Here goes: Let's use http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt as our guide for form and process, and inform its authors if we run into any problems. So, let's at least include the necessary boilerplate items. > "Thank you for the interest in the Alarm MIB. The Distributed Management > (disman) working group hopes to advance the current I-D to Proposed > Standard, with minimal editorial changes. In the future, if the working > group is chartered with an Alarm MIB version 2, we will be interested in > cooperating with you to ensure your requirements are considered." I'd like to make it clear that (as far as I know) we've addressed all their comments. Regarding possible future work, I'd prefer a broader statement. How about "We welcome your input on any disman work items, including discussions of possible future work"? > When we agree on the text, did you want me to get it to SG 4 or did we want > to follow another path? ... Let's see how http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt works. Randy Presuhn, disman WG chair From exim@www1.ietf.org Wed Oct 1 16:24:34 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 QAA02744 for ; Wed, 1 Oct 2003 16:24:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4nW6-00008y-7y for disman-archive@odin.ietf.org; Wed, 01 Oct 2003 16:24:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91KOAKk000551 for disman-archive@odin.ietf.org; Wed, 1 Oct 2003 16:24:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4nW6-00008o-44 for disman-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 16:24:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02719 for ; Wed, 1 Oct 2003 16:24:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4nW4-0004jV-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 16:24:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4nW3-0004jS-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 16:24:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4nVy-00008C-3I; Wed, 01 Oct 2003 16:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4nVw-000080-R0 for disman@optimus.ietf.org; Wed, 01 Oct 2003 16:24:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02712 for ; Wed, 1 Oct 2003 16:23:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4nVu-0004jJ-00 for disman@ietf.org; Wed, 01 Oct 2003 16:23:58 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4nVu-0004jG-00 for disman@ietf.org; Wed, 01 Oct 2003 16:23:58 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4nVp-000758-00 for disman@ietf.org; Wed, 01 Oct 2003 13:23:53 -0700 Message-ID: <000801c38859$cc106800$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408BC0DF1@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm MIB X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 1 Oct 2003 13:22:54 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Wednesday, October 01, 2003 9:58 AM > Subject: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm MIB ... > I took an action out of IETF 56 to draft a response to the liaison from > ITU-T Study Group 4 on Alarm MIB. As the next SG 4 meeting starts on October > 27th, I figured I should finally take a crack at that. We agreed on the > spirit of this text when we last met as a working group. Here goes: Let's use http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt as our guide for form and process, and inform its authors if we run into any problems. So, let's at least include the necessary boilerplate items. > "Thank you for the interest in the Alarm MIB. The Distributed Management > (disman) working group hopes to advance the current I-D to Proposed > Standard, with minimal editorial changes. In the future, if the working > group is chartered with an Alarm MIB version 2, we will be interested in > cooperating with you to ensure your requirements are considered." I'd like to make it clear that (as far as I know) we've addressed all their comments. Regarding possible future work, I'd prefer a broader statement. How about "We welcome your input on any disman work items, including discussions of possible future work"? > When we agree on the text, did you want me to get it to SG 4 or did we want > to follow another path? ... Let's see how http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt works. Randy Presuhn, disman WG chair From disman-admin@ietf.org Wed Oct 1 18:34:29 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 SAA08660 for ; Wed, 1 Oct 2003 18:34:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4pXl-0000VT-7h; Wed, 01 Oct 2003 18:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4pXN-0000V5-7x for disman@optimus.ietf.org; Wed, 01 Oct 2003 18:33:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08612 for ; Wed, 1 Oct 2003 18:33:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4pXK-0006UU-00 for disman@ietf.org; Wed, 01 Oct 2003 18:33:34 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4pXJ-0006UR-00 for disman@ietf.org; Wed, 01 Oct 2003 18:33:33 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4pXI-0005kp-00 for disman@ietf.org; Wed, 01 Oct 2003 15:33:32 -0700 Message-ID: <00aa01c3886b$e9299300$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] Section 3.1 in draft-ietf-disman-alarm-mib-15.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 1 Oct 2003 15:32:34 -0700 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 ... > 12) Page 4: "ITU" acronym should be expanded, for > "ITU model" a reference should be given. ... Although this item was marked "Changed", I see there is still no reference for "ITU model". Is there a rationale for omitting the reference, or was it just an oversight? Randy From exim@www1.ietf.org Wed Oct 1 18:34: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 SAA08675 for ; Wed, 1 Oct 2003 18:34:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4pXs-0000WF-Jf for disman-archive@odin.ietf.org; Wed, 01 Oct 2003 18:34:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91MY8Kj001993 for disman-archive@odin.ietf.org; Wed, 1 Oct 2003 18:34:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4pXs-0000W4-ER for disman-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 18:34:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08628 for ; Wed, 1 Oct 2003 18:33:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4pXp-0006Uq-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 18:34:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4pXo-0006Un-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 18:34:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4pXl-0000VT-7h; Wed, 01 Oct 2003 18:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4pXN-0000V5-7x for disman@optimus.ietf.org; Wed, 01 Oct 2003 18:33:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08612 for ; Wed, 1 Oct 2003 18:33:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4pXK-0006UU-00 for disman@ietf.org; Wed, 01 Oct 2003 18:33:34 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4pXJ-0006UR-00 for disman@ietf.org; Wed, 01 Oct 2003 18:33:33 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4pXI-0005kp-00 for disman@ietf.org; Wed, 01 Oct 2003 15:33:32 -0700 Message-ID: <00aa01c3886b$e9299300$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] Section 3.1 in draft-ietf-disman-alarm-mib-15.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 1 Oct 2003 15:32:34 -0700 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 ... > 12) Page 4: "ITU" acronym should be expanded, for > "ITU model" a reference should be given. ... Although this item was marked "Changed", I see there is still no reference for "ITU model". Is there a rationale for omitting the reference, or was it just an oversight? Randy From disman-admin@ietf.org Wed Oct 1 18:38: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 SAA08854 for ; Wed, 1 Oct 2003 18:38:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4pbf-0000ro-UF; Wed, 01 Oct 2003 18:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4pbI-0000nG-Gn for disman@optimus.ietf.org; Wed, 01 Oct 2003 18:37:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08805 for ; Wed, 1 Oct 2003 18:37:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4pbF-0006Xj-00 for disman@ietf.org; Wed, 01 Oct 2003 18:37:37 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4pbE-0006Xg-00 for disman@ietf.org; Wed, 01 Oct 2003 18:37:37 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4pbE-0004iW-00 for disman@ietf.org; Wed, 01 Oct 2003 15:37:36 -0700 Message-ID: <00ae01c3886c$7ae9e420$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] Unexpanded acronym 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, 1 Oct 2003 15:36:39 -0700 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 ... > 17) Page 6: "OID" acronym should be expanded ... Although this one is marked "Changed", the result is that the acronym now occurs for the first time on page 16, but still without expansion. Randy From exim@www1.ietf.org Wed Oct 1 18:38:28 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 SAA08869 for ; Wed, 1 Oct 2003 18:38:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4pbj-0000st-8E for disman-archive@odin.ietf.org; Wed, 01 Oct 2003 18:38:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91Mc7OO003383 for disman-archive@odin.ietf.org; Wed, 1 Oct 2003 18:38:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4pbh-0000sS-NM for disman-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 18:38:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08817 for ; Wed, 1 Oct 2003 18:37:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4pbe-0006Y4-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 18:38:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4pbe-0006Y1-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 18:38:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4pbf-0000ro-UF; Wed, 01 Oct 2003 18:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4pbI-0000nG-Gn for disman@optimus.ietf.org; Wed, 01 Oct 2003 18:37:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08805 for ; Wed, 1 Oct 2003 18:37:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4pbF-0006Xj-00 for disman@ietf.org; Wed, 01 Oct 2003 18:37:37 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4pbE-0006Xg-00 for disman@ietf.org; Wed, 01 Oct 2003 18:37:37 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4pbE-0004iW-00 for disman@ietf.org; Wed, 01 Oct 2003 15:37:36 -0700 Message-ID: <00ae01c3886c$7ae9e420$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] Unexpanded acronym 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, 1 Oct 2003 15:36:39 -0700 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 ... > 17) Page 6: "OID" acronym should be expanded ... Although this one is marked "Changed", the result is that the acronym now occurs for the first time on page 16, but still without expansion. Randy From disman-admin@ietf.org Wed Oct 1 18:59:22 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 SAA09526 for ; Wed, 1 Oct 2003 18:59:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4pvx-00025I-AW; Wed, 01 Oct 2003 18:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4pvG-00024z-8P for disman@optimus.ietf.org; Wed, 01 Oct 2003 18:58:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09507 for ; Wed, 1 Oct 2003 18:58:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4pvC-0006m5-00 for disman@ietf.org; Wed, 01 Oct 2003 18:58:14 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4pvC-0006m2-00 for disman@ietf.org; Wed, 01 Oct 2003 18:58:14 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4pvC-0006cB-00 for disman@ietf.org; Wed, 01 Oct 2003 15:58:14 -0700 Message-ID: <00b701c3886f$5cbc5660$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] (not) supporting multiple extensions via alarmModelSpecificPointer 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, 1 Oct 2003 15:57:17 -0700 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 ... > 33) Section 4.1.1: one consequence of this approach is that > one cannot use multiple extensions for a single alarm. > So, for example, one couldn't make an extension to the > ITU Alarm MIB and have it work using the method described here. > This may be the intent, but it would be good to be explicit about it. ... The -15- text for section 4.1.1 still doesn't really acknowledge the inherent limitation of alarmModelSpecificPointer. Its syntax limits it to referring to a single extension. If one were to define another MIB containing a table augmenting the ITU alarm stuff, the value of alarmModelSpecificPointer would still presumably point to the ITU alarm stuff rather than the augmentation, so a management station would be left to grope around for this (and any other second- level) extensions. I'm *not* proposing that we change the design. I was (and still am) concerned as a technical contributor that we be upfront about the (perhaps theoretical) design limitation. If no one else cares about this, as WG chair I'm willing to let it go as is. but as a technical contributor I wanted to be sure that folks understood why I'm not 100% happy with the revised text here. Randy Randy From exim@www1.ietf.org Wed Oct 1 18:59: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 SAA09541 for ; Wed, 1 Oct 2003 18:59:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4pvy-000265-ND for disman-archive@odin.ietf.org; Wed, 01 Oct 2003 18:59:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91Mx2uC008055 for disman-archive@odin.ietf.org; Wed, 1 Oct 2003 18:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4pvy-00025q-Iu for disman-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 18:59:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09516 for ; Wed, 1 Oct 2003 18:58:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4pvv-0006mN-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 18:58:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4pvu-0006mK-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 18:58:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4pvx-00025I-AW; Wed, 01 Oct 2003 18:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4pvG-00024z-8P for disman@optimus.ietf.org; Wed, 01 Oct 2003 18:58:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09507 for ; Wed, 1 Oct 2003 18:58:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4pvC-0006m5-00 for disman@ietf.org; Wed, 01 Oct 2003 18:58:14 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4pvC-0006m2-00 for disman@ietf.org; Wed, 01 Oct 2003 18:58:14 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4pvC-0006cB-00 for disman@ietf.org; Wed, 01 Oct 2003 15:58:14 -0700 Message-ID: <00b701c3886f$5cbc5660$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] (not) supporting multiple extensions via alarmModelSpecificPointer 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, 1 Oct 2003 15:57:17 -0700 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 ... > 33) Section 4.1.1: one consequence of this approach is that > one cannot use multiple extensions for a single alarm. > So, for example, one couldn't make an extension to the > ITU Alarm MIB and have it work using the method described here. > This may be the intent, but it would be good to be explicit about it. ... The -15- text for section 4.1.1 still doesn't really acknowledge the inherent limitation of alarmModelSpecificPointer. Its syntax limits it to referring to a single extension. If one were to define another MIB containing a table augmenting the ITU alarm stuff, the value of alarmModelSpecificPointer would still presumably point to the ITU alarm stuff rather than the augmentation, so a management station would be left to grope around for this (and any other second- level) extensions. I'm *not* proposing that we change the design. I was (and still am) concerned as a technical contributor that we be upfront about the (perhaps theoretical) design limitation. If no one else cares about this, as WG chair I'm willing to let it go as is. but as a technical contributor I wanted to be sure that folks understood why I'm not 100% happy with the revised text here. Randy Randy From disman-admin@ietf.org Wed Oct 1 19:06: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 TAA09796 for ; Wed, 1 Oct 2003 19:06:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4q2j-0002JB-OR; Wed, 01 Oct 2003 19:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4q1r-0002Fc-MP for disman@optimus.ietf.org; Wed, 01 Oct 2003 19:05:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09733 for ; Wed, 1 Oct 2003 19:04:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4q1o-0006qf-00 for disman@ietf.org; Wed, 01 Oct 2003 19:05:04 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4q1n-0006qc-00 for disman@ietf.org; Wed, 01 Oct 2003 19:05:04 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4q1o-000276-00 for disman@ietf.org; Wed, 01 Oct 2003 16:05:04 -0700 Message-ID: <00bc01c38870$50ec8b60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] alarm items left to RFC editor 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, 1 Oct 2003 16:04:06 -0700 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 ... > RFC Editor > ---------- > 2) the FF character is merged with the header lines, > resulting in many too-long lines. The RFC editor can > fix these. Agreed. I just wish the secretariat would stop accepting mis-formatted I-Ds. > 7) Page 3: "be able to determine current problems on a system" -> > "be able to determine what the current problems on a system are" > > 13) Page 4: formatting of "Alarm State" paragraph is odd; > there is a premature line break after "also". > > 15a) (global) The document is inconsistent in its use of space > after period at the end of a sentence. There should > consistently be two spaces after each period ending a sentence. > > 16) (global) "modelling" -> "modeling", > "modelled" -> "modeled" > "behaviour" -> "behavior" > A spelling check would be advisable to extirpate the briticisms. ... I think you'll find that you'll end up fixing (7), (13), and (16) yourself during AUTH48, and that not having fixed (15a) yourself will make the task a real pain. I speak from experience. The RFC editor does a superhuman job, but you'll find that errors do creep in, and being able to do a word-for-word check during AUTH48 is important. Randy From exim@www1.ietf.org Wed Oct 1 19:06:24 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 TAA09811 for ; Wed, 1 Oct 2003 19:06:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4q2l-0002K2-G9 for disman-archive@odin.ietf.org; Wed, 01 Oct 2003 19:06:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91N63AG008920 for disman-archive@odin.ietf.org; Wed, 1 Oct 2003 19:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4q2l-0002Jn-Cb for disman-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 19:06:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09790 for ; Wed, 1 Oct 2003 19:05:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4q2h-0006rO-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 19:06:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4q2h-0006rL-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 19:05:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4q2j-0002JB-OR; Wed, 01 Oct 2003 19:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4q1r-0002Fc-MP for disman@optimus.ietf.org; Wed, 01 Oct 2003 19:05:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09733 for ; Wed, 1 Oct 2003 19:04:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4q1o-0006qf-00 for disman@ietf.org; Wed, 01 Oct 2003 19:05:04 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4q1n-0006qc-00 for disman@ietf.org; Wed, 01 Oct 2003 19:05:04 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4q1o-000276-00 for disman@ietf.org; Wed, 01 Oct 2003 16:05:04 -0700 Message-ID: <00bc01c38870$50ec8b60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] alarm items left to RFC editor 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, 1 Oct 2003 16:04:06 -0700 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 ... > RFC Editor > ---------- > 2) the FF character is merged with the header lines, > resulting in many too-long lines. The RFC editor can > fix these. Agreed. I just wish the secretariat would stop accepting mis-formatted I-Ds. > 7) Page 3: "be able to determine current problems on a system" -> > "be able to determine what the current problems on a system are" > > 13) Page 4: formatting of "Alarm State" paragraph is odd; > there is a premature line break after "also". > > 15a) (global) The document is inconsistent in its use of space > after period at the end of a sentence. There should > consistently be two spaces after each period ending a sentence. > > 16) (global) "modelling" -> "modeling", > "modelled" -> "modeled" > "behaviour" -> "behavior" > A spelling check would be advisable to extirpate the briticisms. ... I think you'll find that you'll end up fixing (7), (13), and (16) yourself during AUTH48, and that not having fixed (15a) yourself will make the task a real pain. I speak from experience. The RFC editor does a superhuman job, but you'll find that errors do creep in, and being able to do a word-for-word check during AUTH48 is important. Randy From disman-admin@ietf.org Wed Oct 1 19:24: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 TAA10384 for ; Wed, 1 Oct 2003 19:24:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qK9-0003lr-34; Wed, 01 Oct 2003 19:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qJo-0003lV-67 for disman@optimus.ietf.org; Wed, 01 Oct 2003 19:23:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10357 for ; Wed, 1 Oct 2003 19:23:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4qJm-00072l-00 for disman@ietf.org; Wed, 01 Oct 2003 19:23:38 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4qJm-00072i-00 for disman@ietf.org; Wed, 01 Oct 2003 19:23:38 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4qJm-0000S7-00 for disman@ietf.org; Wed, 01 Oct 2003 16:23:38 -0700 Message-ID: <00c101c38872$e90d0620$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] section 4.1.3 in draft-ietf-disman-alarm-mib-15.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 1 Oct 2003 16:22:41 -0700 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 ... > 35) Section 4.1.3: (see comment 14 above) this paragraph doesn't > tell the whole story of what a manager needs to do to get > these notifications. The sentence beginning with "alternatively" > only makes things worse, since it will result in a configuration > that is contrary to the goal in the paragraph's topic sentence. ... The updated text is better. However, the last sentence in the first paragraph is misleading: in an architecture as described in section 3.2. Specifying no Notifications in the alarmModelNotificationId, regardless of what is defined in the SNMP-TARGET-MIB, would result in no Notifications being logged or sent to management stations. Suggested replacement: in an architecture as described in section 3.2. Specifying no Notifications in the alarmModelNotificationId, regardless of what is defined in the SNMP-TARGET-MIB, would result in no Notifications being logged or sent to management stations as a consequence of this particular alarm state transition. Randy From exim@www1.ietf.org Wed Oct 1 19:24: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 TAA10399 for ; Wed, 1 Oct 2003 19:24:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qKB-0003mj-KT for disman-archive@odin.ietf.org; Wed, 01 Oct 2003 19:24:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91NO3Rl014543 for disman-archive@odin.ietf.org; Wed, 1 Oct 2003 19:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qKB-0003mU-Gr for disman-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 19:24:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10378 for ; Wed, 1 Oct 2003 19:23:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4qK9-00073G-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 19:24:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4qK9-00073D-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 19:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qK9-0003lr-34; Wed, 01 Oct 2003 19:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qJo-0003lV-67 for disman@optimus.ietf.org; Wed, 01 Oct 2003 19:23:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10357 for ; Wed, 1 Oct 2003 19:23:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4qJm-00072l-00 for disman@ietf.org; Wed, 01 Oct 2003 19:23:38 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4qJm-00072i-00 for disman@ietf.org; Wed, 01 Oct 2003 19:23:38 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4qJm-0000S7-00 for disman@ietf.org; Wed, 01 Oct 2003 16:23:38 -0700 Message-ID: <00c101c38872$e90d0620$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] section 4.1.3 in draft-ietf-disman-alarm-mib-15.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 1 Oct 2003 16:22:41 -0700 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 ... > 35) Section 4.1.3: (see comment 14 above) this paragraph doesn't > tell the whole story of what a manager needs to do to get > these notifications. The sentence beginning with "alternatively" > only makes things worse, since it will result in a configuration > that is contrary to the goal in the paragraph's topic sentence. ... The updated text is better. However, the last sentence in the first paragraph is misleading: in an architecture as described in section 3.2. Specifying no Notifications in the alarmModelNotificationId, regardless of what is defined in the SNMP-TARGET-MIB, would result in no Notifications being logged or sent to management stations. Suggested replacement: in an architecture as described in section 3.2. Specifying no Notifications in the alarmModelNotificationId, regardless of what is defined in the SNMP-TARGET-MIB, would result in no Notifications being logged or sent to management stations as a consequence of this particular alarm state transition. Randy From disman-admin@ietf.org Wed Oct 1 19:29:24 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 TAA10488 for ; Wed, 1 Oct 2003 19:29:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qOy-00045R-UT; Wed, 01 Oct 2003 19:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qOD-000453-Pr for disman@optimus.ietf.org; Wed, 01 Oct 2003 19:28:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10464 for ; Wed, 1 Oct 2003 19:28:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4qOC-00074a-00 for disman@ietf.org; Wed, 01 Oct 2003 19:28:12 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4qOB-00074W-00 for disman@ietf.org; Wed, 01 Oct 2003 19:28:11 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4qOB-0007f7-00 for disman@ietf.org; Wed, 01 Oct 2003 16:28:12 -0700 Message-ID: <00c601c38873$8c305460$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] Section 4.1.7 of draft-ietf-disman-alarm-mib-15.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 1 Oct 2003 16:27:14 -0700 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 ... > 42) 4.1.7: "therefore," -> "" ... There's a superfluous comma left over in this line on page 14: named alarm lists. A middle manager could, create an alarmListName Randy From exim@www1.ietf.org Wed Oct 1 19:29: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 TAA10503 for ; Wed, 1 Oct 2003 19:29:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qP1-00048L-0l for disman-archive@odin.ietf.org; Wed, 01 Oct 2003 19:29:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91NT2ha015883 for disman-archive@odin.ietf.org; Wed, 1 Oct 2003 19:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qP0-000486-SB for disman-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 19:29:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10481 for ; Wed, 1 Oct 2003 19:28:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4qOz-00075C-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 19:29:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4qOy-000759-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 19:29:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qOy-00045R-UT; Wed, 01 Oct 2003 19:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qOD-000453-Pr for disman@optimus.ietf.org; Wed, 01 Oct 2003 19:28:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10464 for ; Wed, 1 Oct 2003 19:28:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4qOC-00074a-00 for disman@ietf.org; Wed, 01 Oct 2003 19:28:12 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4qOB-00074W-00 for disman@ietf.org; Wed, 01 Oct 2003 19:28:11 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4qOB-0007f7-00 for disman@ietf.org; Wed, 01 Oct 2003 16:28:12 -0700 Message-ID: <00c601c38873$8c305460$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] Section 4.1.7 of draft-ietf-disman-alarm-mib-15.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 1 Oct 2003 16:27:14 -0700 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 ... > 42) 4.1.7: "therefore," -> "" ... There's a superfluous comma left over in this line on page 14: named alarm lists. A middle manager could, create an alarmListName Randy From disman-admin@ietf.org Wed Oct 1 19:47: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 TAA10830 for ; Wed, 1 Oct 2003 19:47:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qgO-0004hd-P3; Wed, 01 Oct 2003 19:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qgK-0004hO-2z for disman@optimus.ietf.org; Wed, 01 Oct 2003 19:46:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10823 for ; Wed, 1 Oct 2003 19:46:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4qgI-0007DW-00 for disman@ietf.org; Wed, 01 Oct 2003 19:46:54 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A4qgH-0007D0-00 for disman@ietf.org; Wed, 01 Oct 2003 19:46:53 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h91NkLY22537 for ; Wed, 1 Oct 2003 18:46:22 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 2 Oct 2003 01:46:20 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC3D3@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Disman (E-mail) (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: [Disman] draft-ietf-disman-conditionmib 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, 2 Oct 2003 01:46:19 +0200 Here is another comment from an IESG member: > There are two semi-redundant descriptions of the values > for ARC state -- one in the description of the arcTable > object, and the other in the description of arcState. > They don't seem to conflict, but it would be clearer if > they were combined in one location. Do we think it makes sense to remove some (redundant) text? If so, pls suggest which piece to remove. Best in the form of: Replace DESCRIPTION clause of xxx with: Thanks, Bert From exim@www1.ietf.org Wed Oct 1 19:47: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 TAA10845 for ; Wed, 1 Oct 2003 19:47:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qgT-0004iX-C0 for disman-archive@odin.ietf.org; Wed, 01 Oct 2003 19:47:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91Nl53S018127 for disman-archive@odin.ietf.org; Wed, 1 Oct 2003 19:47:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qgT-0004iI-4C for disman-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 19:47:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10827 for ; Wed, 1 Oct 2003 19:46:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4qgR-0007Dc-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 19:47:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4qgQ-0007DZ-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 19:47:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qgO-0004hd-P3; Wed, 01 Oct 2003 19:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qgK-0004hO-2z for disman@optimus.ietf.org; Wed, 01 Oct 2003 19:46:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10823 for ; Wed, 1 Oct 2003 19:46:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4qgI-0007DW-00 for disman@ietf.org; Wed, 01 Oct 2003 19:46:54 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A4qgH-0007D0-00 for disman@ietf.org; Wed, 01 Oct 2003 19:46:53 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h91NkLY22537 for ; Wed, 1 Oct 2003 18:46:22 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 2 Oct 2003 01:46:20 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC3D3@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Disman (E-mail) (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: [Disman] draft-ietf-disman-conditionmib 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, 2 Oct 2003 01:46:19 +0200 Here is another comment from an IESG member: > There are two semi-redundant descriptions of the values > for ARC state -- one in the description of the arcTable > object, and the other in the description of arcState. > They don't seem to conflict, but it would be clearer if > they were combined in one location. Do we think it makes sense to remove some (redundant) text? If so, pls suggest which piece to remove. Best in the form of: Replace DESCRIPTION clause of xxx with: Thanks, Bert From disman-admin@ietf.org Wed Oct 1 19:53: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 TAA10923 for ; Wed, 1 Oct 2003 19:53:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qmD-0005Av-4v; Wed, 01 Oct 2003 19:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qlH-00053Z-MX for disman@optimus.ietf.org; Wed, 01 Oct 2003 19:52:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10889 for ; Wed, 1 Oct 2003 19:51:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4qlF-0007Eg-00 for disman@ietf.org; Wed, 01 Oct 2003 19:52:01 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4qlF-0007Eb-00 for disman@ietf.org; Wed, 01 Oct 2003 19:52:01 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4qlF-0006Vq-00 for disman@ietf.org; Wed, 01 Oct 2003 16:52:01 -0700 Message-ID: <00ca01c38876$e0107800$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] ResourceID TC in draft-ietf-disman-alarm-mib-15.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 1 Oct 2003 16:51:03 -0700 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 ... > 43) page 15 (ResourceId): I agree with the intent of the last > sentence in the description, but if there is a MUST requirement > here, how do we ensure that implementations know what to choose > for any arbitrary table? > > Sharon -> I added this, but I probably should not have. I guess we can > consider it clarifying editorial in nature. ... What's there now is (still) problematic. Specifically: For example, if this resource is an interface, this object MUST point to an ifIndex and if this resource is a physical entity, then this MUST point to an entPhysicalIndex. In general, pointing to objects that act as index into an IETF MIB tables for the resource will provide the most consistency." I see two problems: 1) entPhysicalIndex is not-accessible 2) no guidance is given as to which element of a row should be chosen I suggest borrowing from the description of RowPointer in RFC 2579. Randy From exim@www1.ietf.org Wed Oct 1 19:53:24 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 TAA10938 for ; Wed, 1 Oct 2003 19:53:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qmE-0005Bl-Bn for disman-archive@odin.ietf.org; Wed, 01 Oct 2003 19:53:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91Nr2WW019939 for disman-archive@odin.ietf.org; Wed, 1 Oct 2003 19:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qmE-0005BW-7Z for disman-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 19:53:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10913 for ; Wed, 1 Oct 2003 19:52:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4qmC-0007FJ-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 19:53:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4qmB-0007FG-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 19:52:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qmD-0005Av-4v; Wed, 01 Oct 2003 19:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qlH-00053Z-MX for disman@optimus.ietf.org; Wed, 01 Oct 2003 19:52:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10889 for ; Wed, 1 Oct 2003 19:51:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4qlF-0007Eg-00 for disman@ietf.org; Wed, 01 Oct 2003 19:52:01 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4qlF-0007Eb-00 for disman@ietf.org; Wed, 01 Oct 2003 19:52:01 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4qlF-0006Vq-00 for disman@ietf.org; Wed, 01 Oct 2003 16:52:01 -0700 Message-ID: <00ca01c38876$e0107800$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] ResourceID TC in draft-ietf-disman-alarm-mib-15.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 1 Oct 2003 16:51:03 -0700 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 ... > 43) page 15 (ResourceId): I agree with the intent of the last > sentence in the description, but if there is a MUST requirement > here, how do we ensure that implementations know what to choose > for any arbitrary table? > > Sharon -> I added this, but I probably should not have. I guess we can > consider it clarifying editorial in nature. ... What's there now is (still) problematic. Specifically: For example, if this resource is an interface, this object MUST point to an ifIndex and if this resource is a physical entity, then this MUST point to an entPhysicalIndex. In general, pointing to objects that act as index into an IETF MIB tables for the resource will provide the most consistency." I see two problems: 1) entPhysicalIndex is not-accessible 2) no guidance is given as to which element of a row should be chosen I suggest borrowing from the description of RowPointer in RFC 2579. Randy From disman-admin@ietf.org Wed Oct 1 20:02:24 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 UAA11172 for ; Wed, 1 Oct 2003 20:02:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4quw-0005bJ-3g; Wed, 01 Oct 2003 20:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4quc-0005b3-2k for disman@optimus.ietf.org; Wed, 01 Oct 2003 20:01:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11153 for ; Wed, 1 Oct 2003 20:01:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4qua-0007K6-00 for disman@ietf.org; Wed, 01 Oct 2003 20:01:40 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4quZ-0007K3-00 for disman@ietf.org; Wed, 01 Oct 2003 20:01:39 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4qua-0005df-00 for disman@ietf.org; Wed, 01 Oct 2003 17:01:40 -0700 Message-ID: <00cf01c38878$392847a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] alarmModelRowStatus 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, 1 Oct 2003 17:00:43 -0700 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 ... > 49) alarmModelRowStatus should spell out that the > alarmModelVarbindIndex and alarmModelVarbindValue > MUST be set before row can go active. > > Sharon-> I've fixed this another way. ... AlarmModelRowStatus *still* needs to spell out what objects are necessary for the row to be activated. See http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-02.txt - The DESCRIPTION clause of the status column MUST specify which columnar objects (if any) have to be set to valid values before the row can be activated. If any objects in cascading tables have to be populated with related data before the row can be activated, then this MUST also be specified. Randy From exim@www1.ietf.org Wed Oct 1 20:02: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 UAA11187 for ; Wed, 1 Oct 2003 20:02:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qux-0005c6-V0 for disman-archive@odin.ietf.org; Wed, 01 Oct 2003 20:02:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92023aU021572 for disman-archive@odin.ietf.org; Wed, 1 Oct 2003 20:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4qux-0005br-KD for disman-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 20:02:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11168 for ; Wed, 1 Oct 2003 20:01:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4quv-0007KV-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 20:02:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4quv-0007KS-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 20:02:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4quw-0005bJ-3g; Wed, 01 Oct 2003 20:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4quc-0005b3-2k for disman@optimus.ietf.org; Wed, 01 Oct 2003 20:01:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11153 for ; Wed, 1 Oct 2003 20:01:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4qua-0007K6-00 for disman@ietf.org; Wed, 01 Oct 2003 20:01:40 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4quZ-0007K3-00 for disman@ietf.org; Wed, 01 Oct 2003 20:01:39 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4qua-0005df-00 for disman@ietf.org; Wed, 01 Oct 2003 17:01:40 -0700 Message-ID: <00cf01c38878$392847a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] alarmModelRowStatus 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, 1 Oct 2003 17:00:43 -0700 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 ... > 49) alarmModelRowStatus should spell out that the > alarmModelVarbindIndex and alarmModelVarbindValue > MUST be set before row can go active. > > Sharon-> I've fixed this another way. ... AlarmModelRowStatus *still* needs to spell out what objects are necessary for the row to be activated. See http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-02.txt - The DESCRIPTION clause of the status column MUST specify which columnar objects (if any) have to be set to valid values before the row can be activated. If any objects in cascading tables have to be populated with related data before the row can be activated, then this MUST also be specified. Randy From disman-admin@ietf.org Wed Oct 1 21:06:29 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 VAA12893 for ; Wed, 1 Oct 2003 21:06:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4rus-0000I8-IZ; Wed, 01 Oct 2003 21:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ruB-0000HN-MB for disman@optimus.ietf.org; Wed, 01 Oct 2003 21:05:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12862 for ; Wed, 1 Oct 2003 21:05:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ru9-00004F-00 for disman@ietf.org; Wed, 01 Oct 2003 21:05:17 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4ru8-000048-00 for disman@ietf.org; Wed, 01 Oct 2003 21:05:16 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4ru8-0004ur-00 for disman@ietf.org; Wed, 01 Oct 2003 18:05:16 -0700 Message-ID: <00ef01c38881$1c3b1a60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200310011457.KAA16496@ietf.org> 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] compilation errors in draft-ietf-disman-alarm-mib-15.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 1 Oct 2003 18:04:20 -0700 Hi - Just for fun, I tried to compile the latest alarm mib using the smilint@ibr.cs.tu-bs.de service. There are some problems that need to be fixed before this document can procede. For example: - { 0 0 } instead of { { 0 0 } } in some DEFVALs - alarmModelVarbindIndex is defined twice Randy From exim@www1.ietf.org Wed Oct 1 21:06: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 VAA12908 for ; Wed, 1 Oct 2003 21:06:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ruz-0000P2-CY for disman-archive@odin.ietf.org; Wed, 01 Oct 2003 21:06:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92169cE001547 for disman-archive@odin.ietf.org; Wed, 1 Oct 2003 21:06:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ruz-0000Os-6Z for disman-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 21:06:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12890 for ; Wed, 1 Oct 2003 21:06:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ruw-00004h-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 21:06:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4ruw-00004e-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 21:06:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4rus-0000I8-IZ; Wed, 01 Oct 2003 21:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ruB-0000HN-MB for disman@optimus.ietf.org; Wed, 01 Oct 2003 21:05:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12862 for ; Wed, 1 Oct 2003 21:05:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ru9-00004F-00 for disman@ietf.org; Wed, 01 Oct 2003 21:05:17 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4ru8-000048-00 for disman@ietf.org; Wed, 01 Oct 2003 21:05:16 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4ru8-0004ur-00 for disman@ietf.org; Wed, 01 Oct 2003 18:05:16 -0700 Message-ID: <00ef01c38881$1c3b1a60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200310011457.KAA16496@ietf.org> 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] compilation errors in draft-ietf-disman-alarm-mib-15.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 1 Oct 2003 18:04:20 -0700 Hi - Just for fun, I tried to compile the latest alarm mib using the smilint@ibr.cs.tu-bs.de service. There are some problems that need to be fixed before this document can procede. For example: - { 0 0 } instead of { { 0 0 } } in some DEFVALs - alarmModelVarbindIndex is defined twice Randy From disman-admin@ietf.org Wed Oct 1 21:37: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 VAA13786 for ; Wed, 1 Oct 2003 21:37:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4sOq-0001XU-IJ; Wed, 01 Oct 2003 21:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4sOF-0001Wy-8I for disman@optimus.ietf.org; Wed, 01 Oct 2003 21:36:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13757 for ; Wed, 1 Oct 2003 21:36:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4sOC-0000PY-00 for disman@ietf.org; Wed, 01 Oct 2003 21:36:20 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4sOB-0000PV-00 for disman@ietf.org; Wed, 01 Oct 2003 21:36:20 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4sOC-0007ZW-00 for disman@ietf.org; Wed, 01 Oct 2003 18:36:20 -0700 Message-ID: <010c01c38885$7322e340$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] unthrottleable alarm state change notifications 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, 1 Oct 2003 18:35:23 -0700 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 ... > 55) alarmModelRowStatus does not permit modification of a > model while active alarms exist. This would seem to create > the possibility of "un-throttle-able" alarm storms, contrary > to the spirit of draft-ietf-ops-mib-review-guidelines-01.txt > section 4.7 last paragraph. ... The updated text is still problematic. Specifically, this text remains: This row can not be modified or deleted while it is being referenced by a value of alarmActiveModelPointer. In these As long as there is an active alarm referencing the model, one would not be able to take action using this MIB to throttle it. Also, the entry removal text doesn't specify a lifetime, and the famous five minutes in 2579 are only a suggestion, so the current text really leaves it up to the implementation. This is OK with me, but I want to be sure it's what is intended. Randy From exim@www1.ietf.org Wed Oct 1 21:37: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 VAA13801 for ; Wed, 1 Oct 2003 21:37:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4sOv-0001aJ-JI for disman-archive@odin.ietf.org; Wed, 01 Oct 2003 21:37:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h921b5ZE006080 for disman-archive@odin.ietf.org; Wed, 1 Oct 2003 21:37:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4sOv-0001Zz-51 for disman-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 21:37:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13767 for ; Wed, 1 Oct 2003 21:36:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4sOs-0000Pr-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 21:37:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4sOr-0000Po-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 21:37:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4sOq-0001XU-IJ; Wed, 01 Oct 2003 21:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4sOF-0001Wy-8I for disman@optimus.ietf.org; Wed, 01 Oct 2003 21:36:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13757 for ; Wed, 1 Oct 2003 21:36:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4sOC-0000PY-00 for disman@ietf.org; Wed, 01 Oct 2003 21:36:20 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4sOB-0000PV-00 for disman@ietf.org; Wed, 01 Oct 2003 21:36:20 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4sOC-0007ZW-00 for disman@ietf.org; Wed, 01 Oct 2003 18:36:20 -0700 Message-ID: <010c01c38885$7322e340$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] unthrottleable alarm state change notifications 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, 1 Oct 2003 18:35:23 -0700 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 ... > 55) alarmModelRowStatus does not permit modification of a > model while active alarms exist. This would seem to create > the possibility of "un-throttle-able" alarm storms, contrary > to the spirit of draft-ietf-ops-mib-review-guidelines-01.txt > section 4.7 last paragraph. ... The updated text is still problematic. Specifically, this text remains: This row can not be modified or deleted while it is being referenced by a value of alarmActiveModelPointer. In these As long as there is an active alarm referencing the model, one would not be able to take action using this MIB to throttle it. Also, the entry removal text doesn't specify a lifetime, and the famous five minutes in 2579 are only a suggestion, so the current text really leaves it up to the implementation. This is OK with me, but I want to be sure it's what is intended. Randy From disman-admin@ietf.org Wed Oct 1 21:52:24 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 VAA14135 for ; Wed, 1 Oct 2003 21:52:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4sdN-0002KT-E1; Wed, 01 Oct 2003 21:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4scm-0002GF-51 for disman@optimus.ietf.org; Wed, 01 Oct 2003 21:51:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14126 for ; Wed, 1 Oct 2003 21:51:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4scj-0000YY-00 for disman@ietf.org; Wed, 01 Oct 2003 21:51:21 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4sci-0000YV-00 for disman@ietf.org; Wed, 01 Oct 2003 21:51:20 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4sci-00006G-00 for disman@ietf.org; Wed, 01 Oct 2003 18:51:20 -0700 Message-ID: <011301c38887$ad3378e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] alarmActiveEngineAddress 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, 1 Oct 2003 18:51:20 -0700 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 ... ... > 58) alarmActiveEngineAddress: "IP Address" -> "address" > ditto alarmClearEngineAddress ... One step forward, two steps back. :-) * 0.5 - "Address" should be "address" - the sentence "This is used to identify the source of an SNMPv1 trap, since an alarmActiveEngineId cannot be extracted from the SNMPv1 trap PDU." leaves me wondering why it's there, since even if one can extract an SnmpEngineId from a wrapper, it still won't reliably yield an address. Randy From exim@www1.ietf.org Wed Oct 1 21:52: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 VAA14150 for ; Wed, 1 Oct 2003 21:52:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4sdP-0002LF-9U for disman-archive@odin.ietf.org; Wed, 01 Oct 2003 21:52:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h921q3iH008995 for disman-archive@odin.ietf.org; Wed, 1 Oct 2003 21:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4sdP-0002L0-5O for disman-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 21:52:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14132 for ; Wed, 1 Oct 2003 21:51:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4sdM-0000Yj-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 21:52:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4sdL-0000Yg-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 21:51:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4sdN-0002KT-E1; Wed, 01 Oct 2003 21:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4scm-0002GF-51 for disman@optimus.ietf.org; Wed, 01 Oct 2003 21:51:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14126 for ; Wed, 1 Oct 2003 21:51:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4scj-0000YY-00 for disman@ietf.org; Wed, 01 Oct 2003 21:51:21 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4sci-0000YV-00 for disman@ietf.org; Wed, 01 Oct 2003 21:51:20 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4sci-00006G-00 for disman@ietf.org; Wed, 01 Oct 2003 18:51:20 -0700 Message-ID: <011301c38887$ad3378e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] alarmActiveEngineAddress 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, 1 Oct 2003 18:51:20 -0700 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 ... ... > 58) alarmActiveEngineAddress: "IP Address" -> "address" > ditto alarmClearEngineAddress ... One step forward, two steps back. :-) * 0.5 - "Address" should be "address" - the sentence "This is used to identify the source of an SNMPv1 trap, since an alarmActiveEngineId cannot be extracted from the SNMPv1 trap PDU." leaves me wondering why it's there, since even if one can extract an SnmpEngineId from a wrapper, it still won't reliably yield an address. Randy From disman-admin@ietf.org Wed Oct 1 23:52:28 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 XAA17581 for ; Wed, 1 Oct 2003 23:52:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uVV-0000cF-F8; Wed, 01 Oct 2003 23:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uV2-0000bo-Cb for disman@optimus.ietf.org; Wed, 01 Oct 2003 23:51:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17563 for ; Wed, 1 Oct 2003 23:51:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4uV0-0001rz-00 for disman@ietf.org; Wed, 01 Oct 2003 23:51:30 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4uUz-0001rw-00 for disman@ietf.org; Wed, 01 Oct 2003 23:51:29 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4uV0-0005Nc-00 for disman@ietf.org; Wed, 01 Oct 2003 20:51:30 -0700 Message-ID: <013101c38898$7682dc80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 1 Oct 2003 20:51:29 -0700 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 ... > 59) alarmActiveContextName: this is defined to be an SnmpAdminString. > This is fine for the case where its value is a context name. > However, in the case where it is a community, provision needs > to be made for the possibility that the community name would not > be a well-formed SnmpAdminString. (for example, 0xFF would be > a legal community, but would violate the rules for UTF-8.) > ditto alarmClearContextName ... I think this probalem hasn't been addressed. The current text says: alarmClearContextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the SNMP MIB context from which the alarm came. For SNMPv1 traps 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 an SNMPv1 trap had a community string with a value of 0xFF, what value would the corresponding instance of this object have? The alarm MIB implementation has no control over the community strings it might encounter. If the alarm's source SNMP engine is known not to support multiple contexts, this object is a zero length string." ::= { alarmClearEntry 6 } Is this intended to be a MUST or a MAY? Randy From exim@www1.ietf.org Wed Oct 1 23:52:29 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 XAA17596 for ; Wed, 1 Oct 2003 23:52:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uVa-0000d3-Iz for disman-archive@odin.ietf.org; Wed, 01 Oct 2003 23:52:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h923q6Np002411 for disman-archive@odin.ietf.org; Wed, 1 Oct 2003 23:52:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uVa-0000co-Fh for disman-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 23:52:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17576 for ; Wed, 1 Oct 2003 23:51:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4uVY-0001sH-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 23:52:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4uVX-0001sE-00 for disman-web-archive@ietf.org; Wed, 01 Oct 2003 23:52:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uVV-0000cF-F8; Wed, 01 Oct 2003 23:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uV2-0000bo-Cb for disman@optimus.ietf.org; Wed, 01 Oct 2003 23:51:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17563 for ; Wed, 1 Oct 2003 23:51:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4uV0-0001rz-00 for disman@ietf.org; Wed, 01 Oct 2003 23:51:30 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A4uUz-0001rw-00 for disman@ietf.org; Wed, 01 Oct 2003 23:51:29 -0400 Received: from h-68-164-20-19.snvacaid.dynamic.covad.net ([68.164.20.19] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A4uV0-0005Nc-00 for disman@ietf.org; Wed, 01 Oct 2003 20:51:30 -0700 Message-ID: <013101c38898$7682dc80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 1 Oct 2003 20:51:29 -0700 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 ... > 59) alarmActiveContextName: this is defined to be an SnmpAdminString. > This is fine for the case where its value is a context name. > However, in the case where it is a community, provision needs > to be made for the possibility that the community name would not > be a well-formed SnmpAdminString. (for example, 0xFF would be > a legal community, but would violate the rules for UTF-8.) > ditto alarmClearContextName ... I think this probalem hasn't been addressed. The current text says: alarmClearContextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the SNMP MIB context from which the alarm came. For SNMPv1 traps 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 an SNMPv1 trap had a community string with a value of 0xFF, what value would the corresponding instance of this object have? The alarm MIB implementation has no control over the community strings it might encounter. If the alarm's source SNMP engine is known not to support multiple contexts, this object is a zero length string." ::= { alarmClearEntry 6 } Is this intended to be a MUST or a MAY? Randy From disman-admin@ietf.org Thu Oct 2 03:43:34 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 DAA06356 for ; Thu, 2 Oct 2003 03:43:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4y73-0004ut-8J; Thu, 02 Oct 2003 03:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4y6J-0004qd-Uf for disman@optimus.ietf.org; Thu, 02 Oct 2003 03:42:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06344 for ; Thu, 2 Oct 2003 03:42:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4y6H-0004Cd-00 for disman@ietf.org; Thu, 02 Oct 2003 03:42:13 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1A4y6G-0004Ca-00 for disman@ietf.org; Thu, 02 Oct 2003 03:42:12 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h927eOJK003381 for ; Thu, 2 Oct 2003 02:40:24 -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 h927eMJK003362 for ; Thu, 2 Oct 2003 02:40:23 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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 3.1 in draft-ietf-disman-alarm-mib-15.txt Message-ID: Thread-Topic: [Disman] Section 3.1 in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOIbCqbxAuvamVkRv2IE2/FqUO77AATDdoQ 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: Thu, 2 Oct 2003 10:42:09 +0300 Content-Transfer-Encoding: quoted-printable > ... > > 12) Page 4: "ITU" acronym should be expanded, for > > "ITU model" a reference should be given. > ... >=20 > Although this item was marked "Changed", I see there is still > no reference for "ITU model". Is there a rationale for omitting > the reference, or was it just an oversight? The reference should be to the ITU Alarm MIB in section 5.4 of the same = document.=20 >=20 > Randy >=20 >=20 >=20 >=20 From exim@www1.ietf.org Thu Oct 2 03:43:36 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 DAA06371 for ; Thu, 2 Oct 2003 03:43:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4y7F-0004yX-NH for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 03:43:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h927hDqU019119 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 03:43:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4y7F-0004yI-AS for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 03:43:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06352 for ; Thu, 2 Oct 2003 03:43:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4y7C-0004Cw-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 03:43:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4y7C-0004Ct-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 03:43:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4y73-0004ut-8J; Thu, 02 Oct 2003 03:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4y6J-0004qd-Uf for disman@optimus.ietf.org; Thu, 02 Oct 2003 03:42:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06344 for ; Thu, 2 Oct 2003 03:42:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4y6H-0004Cd-00 for disman@ietf.org; Thu, 02 Oct 2003 03:42:13 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1A4y6G-0004Ca-00 for disman@ietf.org; Thu, 02 Oct 2003 03:42:12 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h927eOJK003381 for ; Thu, 2 Oct 2003 02:40:24 -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 h927eMJK003362 for ; Thu, 2 Oct 2003 02:40:23 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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 3.1 in draft-ietf-disman-alarm-mib-15.txt Message-ID: Thread-Topic: [Disman] Section 3.1 in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOIbCqbxAuvamVkRv2IE2/FqUO77AATDdoQ 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: Thu, 2 Oct 2003 10:42:09 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > ... > > 12) Page 4: "ITU" acronym should be expanded, for > > "ITU model" a reference should be given. > ... >=20 > Although this item was marked "Changed", I see there is still > no reference for "ITU model". Is there a rationale for omitting > the reference, or was it just an oversight? The reference should be to the ITU Alarm MIB in section 5.4 of the same = document.=20 >=20 > Randy >=20 >=20 >=20 >=20 From disman-admin@ietf.org Thu Oct 2 03:52: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 DAA06562 for ; Thu, 2 Oct 2003 03:52:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yFl-0005Me-84; Thu, 02 Oct 2003 03:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yF0-0005Kr-UD for disman@optimus.ietf.org; Thu, 02 Oct 2003 03:51:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06535 for ; Thu, 2 Oct 2003 03:51:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4yEy-0004HQ-00 for disman@ietf.org; Thu, 02 Oct 2003 03:51:12 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1A4yEx-0004HN-00 for disman@ietf.org; Thu, 02 Oct 2003 03:51:11 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h927nOJK006469 for ; Thu, 2 Oct 2003 02:49:24 -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 h927nLJK006464 for ; Thu, 2 Oct 2003 02:49:23 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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] alarmModelRowStatus Message-ID: Thread-Topic: [Disman] alarmModelRowStatus Thread-Index: AcOIeHAwDU9slrIPTkmEjmoN+ekl/QAQQZBA 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: Thu, 2 Oct 2003 10:51:07 +0300 Content-Transfer-Encoding: quoted-printable > > 49) alarmModelRowStatus should spell out that the > > alarmModelVarbindIndex and alarmModelVarbindValue > > MUST be set before row can go active. > > > > Sharon-> I've fixed this another way. > ... >=20 > AlarmModelRowStatus *still* needs to spell out what objects=20 > are necessary > for the row to be activated. See > http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review- > guidelines-02.txt >=20 >=20 > - The DESCRIPTION clause of the status column MUST specify which > columnar objects (if any) have to be set to valid values before > the row can be activated. If any objects in cascading tables > have to be populated with related data before the row can be > activated, then this MUST also be specified. >=20 >=20 > Randy >=20 Actually all read-create objects have a DEFVAL clause. If one would = create a row without setting any of them, no harm would happen, other = than a useless row being created. Do we need to say in this case that = 'syntactically you can do it, bit it would be a loss of time'? Dan >=20 >=20 >=20 From exim@www1.ietf.org Thu Oct 2 03:52:24 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 DAA06577 for ; Thu, 2 Oct 2003 03:52:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yFn-0005NW-16 for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 03:52:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h927q2HG020670 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 03:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yFm-0005NJ-DP for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 03:52:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06556 for ; Thu, 2 Oct 2003 03:51:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4yFj-0004I0-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 03:51:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4yFj-0004Hx-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 03:51:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yFl-0005Me-84; Thu, 02 Oct 2003 03:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yF0-0005Kr-UD for disman@optimus.ietf.org; Thu, 02 Oct 2003 03:51:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06535 for ; Thu, 2 Oct 2003 03:51:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4yEy-0004HQ-00 for disman@ietf.org; Thu, 02 Oct 2003 03:51:12 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1A4yEx-0004HN-00 for disman@ietf.org; Thu, 02 Oct 2003 03:51:11 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h927nOJK006469 for ; Thu, 2 Oct 2003 02:49:24 -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 h927nLJK006464 for ; Thu, 2 Oct 2003 02:49:23 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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] alarmModelRowStatus Message-ID: Thread-Topic: [Disman] alarmModelRowStatus Thread-Index: AcOIeHAwDU9slrIPTkmEjmoN+ekl/QAQQZBA 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: Thu, 2 Oct 2003 10:51:07 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > 49) alarmModelRowStatus should spell out that the > > alarmModelVarbindIndex and alarmModelVarbindValue > > MUST be set before row can go active. > > > > Sharon-> I've fixed this another way. > ... >=20 > AlarmModelRowStatus *still* needs to spell out what objects=20 > are necessary > for the row to be activated. See > http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review- > guidelines-02.txt >=20 >=20 > - The DESCRIPTION clause of the status column MUST specify which > columnar objects (if any) have to be set to valid values before > the row can be activated. If any objects in cascading tables > have to be populated with related data before the row can be > activated, then this MUST also be specified. >=20 >=20 > Randy >=20 Actually all read-create objects have a DEFVAL clause. If one would = create a row without setting any of them, no harm would happen, other = than a useless row being created. Do we need to say in this case that = 'syntactically you can do it, bit it would be a loss of time'? Dan >=20 >=20 >=20 From disman-admin@ietf.org Thu Oct 2 03:56: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 DAA06699 for ; Thu, 2 Oct 2003 03:56:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yJd-0005a1-Uk; Thu, 02 Oct 2003 03:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yJH-0005Z4-0l for disman@optimus.ietf.org; Thu, 02 Oct 2003 03:55:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06663 for ; Thu, 2 Oct 2003 03:55:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4yJE-0004Km-00 for disman@ietf.org; Thu, 02 Oct 2003 03:55:36 -0400 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1A4yJD-0004Kj-00 for disman@ietf.org; Thu, 02 Oct 2003 03:55:35 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h927tFoT022308 for ; Thu, 2 Oct 2003 03:55:15 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h927tCoT022272 for ; Thu, 2 Oct 2003 03:55:13 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt Message-ID: Thread-Topic: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOImJ4sWR2waoevSbut1FV6yfwMiQAIbm0g 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: Thu, 2 Oct 2003 10:55:32 +0300 Content-Transfer-Encoding: quoted-printable > > 59) alarmActiveContextName: this is defined to be an=20 > SnmpAdminString. > > This is fine for the case where its value is a context name. > > However, in the case where it is a community, provision needs > > to be made for the possibility that the community name would not > > be a well-formed SnmpAdminString. (for example, 0xFF would be > > a legal community, but would violate the rules for UTF-8.) > > ditto alarmClearContextName > ... >=20 > I think this probalem hasn't been addressed. > The current text says: >=20 > alarmClearContextName OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE(0..32)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The name of the SNMP MIB context from which the alarm came. > For SNMPv1 traps 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. >=20 > If an SNMPv1 trap had a community string with a value of 0xFF, > what value would the corresponding instance of this object have? > The alarm MIB implementation has no control over the community > strings it might encounter. >=20 > If the alarm's source SNMP engine is known not to support > multiple contexts, this object is a zero length string." > ::=3D { alarmClearEntry 6 } >=20 >=20 > Is this intended to be a MUST or a MAY? >=20 > Randy The solution is to make the text crisper that community strings can be = represented. This means a couple of MUSTs in the two places quoted by = Randy. >=20 >=20 >=20 >=20 >=20 From exim@www1.ietf.org Thu Oct 2 03:56: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 DAA06714 for ; Thu, 2 Oct 2003 03:56:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yJi-0005bg-49 for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 03:56:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h927u5Ws021546 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 03:56:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yJh-0005bR-49 for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 03:56:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06671 for ; Thu, 2 Oct 2003 03:55:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4yJe-0004LP-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 03:56:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4yJd-0004LM-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 03:56:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yJd-0005a1-Uk; Thu, 02 Oct 2003 03:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yJH-0005Z4-0l for disman@optimus.ietf.org; Thu, 02 Oct 2003 03:55:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06663 for ; Thu, 2 Oct 2003 03:55:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4yJE-0004Km-00 for disman@ietf.org; Thu, 02 Oct 2003 03:55:36 -0400 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1A4yJD-0004Kj-00 for disman@ietf.org; Thu, 02 Oct 2003 03:55:35 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h927tFoT022308 for ; Thu, 2 Oct 2003 03:55:15 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h927tCoT022272 for ; Thu, 2 Oct 2003 03:55:13 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt Message-ID: Thread-Topic: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOImJ4sWR2waoevSbut1FV6yfwMiQAIbm0g 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: Thu, 2 Oct 2003 10:55:32 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > 59) alarmActiveContextName: this is defined to be an=20 > SnmpAdminString. > > This is fine for the case where its value is a context name. > > However, in the case where it is a community, provision needs > > to be made for the possibility that the community name would not > > be a well-formed SnmpAdminString. (for example, 0xFF would be > > a legal community, but would violate the rules for UTF-8.) > > ditto alarmClearContextName > ... >=20 > I think this probalem hasn't been addressed. > The current text says: >=20 > alarmClearContextName OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE(0..32)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The name of the SNMP MIB context from which the alarm came. > For SNMPv1 traps 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. >=20 > If an SNMPv1 trap had a community string with a value of 0xFF, > what value would the corresponding instance of this object have? > The alarm MIB implementation has no control over the community > strings it might encounter. >=20 > If the alarm's source SNMP engine is known not to support > multiple contexts, this object is a zero length string." > ::=3D { alarmClearEntry 6 } >=20 >=20 > Is this intended to be a MUST or a MAY? >=20 > Randy The solution is to make the text crisper that community strings can be = represented. This means a couple of MUSTs in the two places quoted by = Randy. >=20 >=20 >=20 >=20 >=20 From disman-admin@ietf.org Thu Oct 2 06:37: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 GAA11205 for ; Thu, 2 Oct 2003 06:37:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A50pQ-0005jU-P4; Thu, 02 Oct 2003 06:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A50oZ-0005if-2w for disman@optimus.ietf.org; Thu, 02 Oct 2003 06:36:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11173 for ; Thu, 2 Oct 2003 06:35:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A50oU-0005uY-00 for disman@ietf.org; Thu, 02 Oct 2003 06:36:02 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A50oU-0005uP-00 for disman@ietf.org; Thu, 02 Oct 2003 06:36:02 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h92AaCk29279 for ; Thu, 2 Oct 2003 05:36:12 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 2 Oct 2003 12:35:29 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC3E4@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Lam, Hing-Kam (Kam)" , "Disman (E-mail) (E-mail)" Cc: "Ted Hardie (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [Disman] Another IESG comment - pls respond ASAP 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, 2 Oct 2003 12:35:22 +0200 WG/Authors/editors, dow we want to do something about the following: Ted Hardie: Buried in the ARCState description is: " Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., in the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. This seems a major enough design decision on how to accomplish the work to move it into the text of the document or repeat it there. Thanks, Bert From exim@www1.ietf.org Thu Oct 2 06:37: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 GAA11225 for ; Thu, 2 Oct 2003 06:37:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A50pX-0005l3-OB for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 06:37:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Ab7Pl022127 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 06:37:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A50pX-0005ko-BY for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 06:37:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11196 for ; Thu, 2 Oct 2003 06:36:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A50pT-0005vB-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 06:37:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A50pS-0005v7-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 06:37:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A50pQ-0005jU-P4; Thu, 02 Oct 2003 06:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A50oZ-0005if-2w for disman@optimus.ietf.org; Thu, 02 Oct 2003 06:36:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11173 for ; Thu, 2 Oct 2003 06:35:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A50oU-0005uY-00 for disman@ietf.org; Thu, 02 Oct 2003 06:36:02 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A50oU-0005uP-00 for disman@ietf.org; Thu, 02 Oct 2003 06:36:02 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h92AaCk29279 for ; Thu, 2 Oct 2003 05:36:12 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 2 Oct 2003 12:35:29 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC3E4@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Lam, Hing-Kam (Kam)" , "Disman (E-mail) (E-mail)" Cc: "Ted Hardie (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [Disman] Another IESG comment - pls respond ASAP 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, 2 Oct 2003 12:35:22 +0200 WG/Authors/editors, dow we want to do something about the following: Ted Hardie: Buried in the ARCState description is: " Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., in the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. This seems a major enough design decision on how to accomplish the work to move it into the text of the document or repeat it there. Thanks, Bert From disman-admin@ietf.org Thu Oct 2 08:45:29 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 IAA16451 for ; Thu, 2 Oct 2003 08:45:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A52pL-0004fU-64; Thu, 02 Oct 2003 08:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A52oj-0004cz-Jn for disman@optimus.ietf.org; Thu, 02 Oct 2003 08:44:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16379 for ; Thu, 2 Oct 2003 08:44:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A52oi-0007jW-00 for disman@ietf.org; Thu, 02 Oct 2003 08:44:24 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A52oh-0007j0-00 for disman@ietf.org; Thu, 02 Oct 2003 08:44:23 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h92ChoN08719 for ; Thu, 2 Oct 2003 07:43:51 -0500 (CDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 2 Oct 2003 08:43:50 -0400 Message-ID: From: "Lam, Hing-Kam (Kam)" To: "Wijnen, Bert (Bert)" , "Disman (E-mail) (E-mail)" Subject: RE: [Disman] draft-ietf-disman-conditionmib MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 2 Oct 2003 08:43:49 -0400 Okay. Consolidate the ARC state definition and transition into the DESCRIPTION clause of the arcState object as follow. Thanks. Regards, Kam ----------Start------ Replace DESCRIPTION clause of arcTable with: DESCRIPTION "A table of Alarm Reporting Control (ARC) settings on the system. Alarm Reporting Control is a feature that provides an automatic in-service provisioning capability. Alarm reporting is turned off on a per-resource basis for a selective set of potential alarm conditions to allow sufficient time for customer testing and other maintenance activities in an 'alarm free' state. Once a resource is ready for service, alarm reporting is automatically or manually turned on. Functional description and requirements of Alarm Reporting Control are defined in ITU-T Recommendation M.3100 Amendment 3 [M.3100 Amd3]." Replace DESCRIPTION clause of arcState with: DESCRIPTION "Defined in M.3100 Amendment 3 [M.3100 Amd3], there are five ARC states: alm, nalm, nalmQI, nalmQICD, and nalmTI. alm: Alarm reporting is turned on (i.e., is allowed). nalm: Alarm reporting is turned off (i.e., not allowed). nalmQI: nalm - Qualified Inhibit. Alarm reporting is turned off until the managed entity is qualified problem-free for an optional persistence interval. Problem-free means that the condition corresponding to the specified alarm type is cleared. nalmQICD: nalmQI - Count down. This is a substate of nalmQI and performs the persistence timing countdown function after the managed entity is qualified problem-free. nalmTI: nalm - Timed Inhibit. Alarm reporting is turned off for a specified time interval. alm may transition to nalm, nalmQI or nalmTI by management request. nalm may transition to alm, nalmQI or nalmTI by management request. nalmQI may transition to nalm or alm by management request. nalmQI may transition to alm automatically if qualified problem-free (if nalmQICD is not supported) or if the CD timer expired (if nalmQICD is supported) nalmTI may transition to alm or nalm by management request. nalmTI may transition to alm automatically if the TI timer expired. Further details of ARC state transitions are defined in Figure 3 of M.3100 Amd3 [M.3100 Amd3]. According to the requirements in M.3100 Amd3, a resource supporting the ARC feature shall support the alm state and at least one of the nalm, nalmTI, and nalmQI states. The nalmQICD state is an optional substate of nalmQI. The arcState object controls the alarm reporting state of a resource. Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., in the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. The nalamQICD state is a transitional state from nalmQI to alm. It is optional depending on the resource type and the implementation of the the resource. If it is supported, before the state transitions from nalmQI to alm, a count down period is activated for a duration set by the object arcNalmCDTimeInterval. When the time is up, the arcState transitions to alm." --------End---------- > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Wednesday, October 01, 2003 7:46 PM > To: Disman (E-mail) (E-mail) > Subject: [Disman] draft-ietf-disman-conditionmib > > > Here is another comment from an IESG member: > > > There are two semi-redundant descriptions of the values > > for ARC state -- one in the description of the arcTable > > object, and the other in the description of arcState. > > They don't seem to conflict, but it would be clearer if > > they were combined in one location. > > Do we think it makes sense to remove some (redundant) text? > If so, pls suggest which piece to remove. Best in the form > of: > > Replace DESCRIPTION clause of xxx with: > > Thanks, > Bert > From exim@www1.ietf.org Thu Oct 2 08:45: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 IAA16466 for ; Thu, 2 Oct 2003 08:45:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A52pQ-0004hA-K3 for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 08:45:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Cj8xi018042 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 08:45:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A52pQ-0004gv-Gx for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 08:45:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16395 for ; Thu, 2 Oct 2003 08:44:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A52pP-0007ka-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 08:45:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A52pO-0007kX-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 08:45:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A52pL-0004fU-64; Thu, 02 Oct 2003 08:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A52oj-0004cz-Jn for disman@optimus.ietf.org; Thu, 02 Oct 2003 08:44:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16379 for ; Thu, 2 Oct 2003 08:44:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A52oi-0007jW-00 for disman@ietf.org; Thu, 02 Oct 2003 08:44:24 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A52oh-0007j0-00 for disman@ietf.org; Thu, 02 Oct 2003 08:44:23 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h92ChoN08719 for ; Thu, 2 Oct 2003 07:43:51 -0500 (CDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 2 Oct 2003 08:43:50 -0400 Message-ID: From: "Lam, Hing-Kam (Kam)" To: "Wijnen, Bert (Bert)" , "Disman (E-mail) (E-mail)" Subject: RE: [Disman] draft-ietf-disman-conditionmib MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 2 Oct 2003 08:43:49 -0400 Okay. Consolidate the ARC state definition and transition into the DESCRIPTION clause of the arcState object as follow. Thanks. Regards, Kam ----------Start------ Replace DESCRIPTION clause of arcTable with: DESCRIPTION "A table of Alarm Reporting Control (ARC) settings on the system. Alarm Reporting Control is a feature that provides an automatic in-service provisioning capability. Alarm reporting is turned off on a per-resource basis for a selective set of potential alarm conditions to allow sufficient time for customer testing and other maintenance activities in an 'alarm free' state. Once a resource is ready for service, alarm reporting is automatically or manually turned on. Functional description and requirements of Alarm Reporting Control are defined in ITU-T Recommendation M.3100 Amendment 3 [M.3100 Amd3]." Replace DESCRIPTION clause of arcState with: DESCRIPTION "Defined in M.3100 Amendment 3 [M.3100 Amd3], there are five ARC states: alm, nalm, nalmQI, nalmQICD, and nalmTI. alm: Alarm reporting is turned on (i.e., is allowed). nalm: Alarm reporting is turned off (i.e., not allowed). nalmQI: nalm - Qualified Inhibit. Alarm reporting is turned off until the managed entity is qualified problem-free for an optional persistence interval. Problem-free means that the condition corresponding to the specified alarm type is cleared. nalmQICD: nalmQI - Count down. This is a substate of nalmQI and performs the persistence timing countdown function after the managed entity is qualified problem-free. nalmTI: nalm - Timed Inhibit. Alarm reporting is turned off for a specified time interval. alm may transition to nalm, nalmQI or nalmTI by management request. nalm may transition to alm, nalmQI or nalmTI by management request. nalmQI may transition to nalm or alm by management request. nalmQI may transition to alm automatically if qualified problem-free (if nalmQICD is not supported) or if the CD timer expired (if nalmQICD is supported) nalmTI may transition to alm or nalm by management request. nalmTI may transition to alm automatically if the TI timer expired. Further details of ARC state transitions are defined in Figure 3 of M.3100 Amd3 [M.3100 Amd3]. According to the requirements in M.3100 Amd3, a resource supporting the ARC feature shall support the alm state and at least one of the nalm, nalmTI, and nalmQI states. The nalmQICD state is an optional substate of nalmQI. The arcState object controls the alarm reporting state of a resource. Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., in the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. The nalamQICD state is a transitional state from nalmQI to alm. It is optional depending on the resource type and the implementation of the the resource. If it is supported, before the state transitions from nalmQI to alm, a count down period is activated for a duration set by the object arcNalmCDTimeInterval. When the time is up, the arcState transitions to alm." --------End---------- > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Wednesday, October 01, 2003 7:46 PM > To: Disman (E-mail) (E-mail) > Subject: [Disman] draft-ietf-disman-conditionmib > > > Here is another comment from an IESG member: > > > There are two semi-redundant descriptions of the values > > for ARC state -- one in the description of the arcTable > > object, and the other in the description of arcState. > > They don't seem to conflict, but it would be clearer if > > they were combined in one location. > > Do we think it makes sense to remove some (redundant) text? > If so, pls suggest which piece to remove. Best in the form > of: > > Replace DESCRIPTION clause of xxx with: > > Thanks, > Bert > From disman-admin@ietf.org Thu Oct 2 08:59:24 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 IAA17056 for ; Thu, 2 Oct 2003 08:59:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A532q-0005TF-Ne; Thu, 02 Oct 2003 08:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A532O-0005Rt-8N for disman@optimus.ietf.org; Thu, 02 Oct 2003 08:58:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16997 for ; Thu, 2 Oct 2003 08:58:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A532M-00008l-00 for disman@ietf.org; Thu, 02 Oct 2003 08:58:30 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A532M-00008R-00 for disman@ietf.org; Thu, 02 Oct 2003 08:58:30 -0400 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h92CvvN14034 for ; Thu, 2 Oct 2003 07:57:57 -0500 (CDT) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 2 Oct 2003 08:57:56 -0400 Message-ID: From: "Lam, Hing-Kam (Kam)" To: "Wijnen, Bert (Bert)" , "'Disman (E-mail) (E-mail)'" Cc: "'Ted Hardie (E-mail)'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [Disman] RE: Another IESG comment - pls respond ASAP 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, 2 Oct 2003 08:57:55 -0400 Thanks for the comment. I will propose the following to highlight the design. In Section 4 "ARC MIB Overview", add the following text as a new paragraph after the 5th paragraph (The 5th paragraph is the one starts with the sentence: This document defines ....) Defined in M.3100 Amendment 3 [M.3100 Amd3], there are five ARC states: alm, nalm, nalmQI, nalmQICD and nalmTI. In the ARC MIB module, the arcState object is defined to model the M.3100 ARC states. Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., into the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. Regards, Kam > -----Original Message----- > From: Wijnen, Bert (Bert) > Sent: Thursday, October 02, 2003 6:35 AM > To: Lam, Hing-Kam (Kam); Disman (E-mail) (E-mail) > Cc: Ted Hardie (E-mail) > Subject: Another IESG comment - pls respond ASAP > > > WG/Authors/editors, dow we want to do something > about the following: > > Ted Hardie: > Buried in the ARCState description is: > > " Note that the state alm (alarm reporting is allowed) is not listed > in the enumeration of the value of this object. However, this > state is implicitly supported by the mib. > Once a resource enters the normal reporting mode (i.e., > in the alm > state) for the specified alarm type, the corresponding > row will be automatically deleted from the arc table. > Also the manual setting of arcState to alm can be achieved through > setting the RowStatus object to 'destroy'. > > This seems a major enough design decision on how to accomplish > the work to move it into the text of the document or repeat > it there. > > Thanks, > Bert > From exim@www1.ietf.org Thu Oct 2 08:59: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 IAA17071 for ; Thu, 2 Oct 2003 08:59:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A532u-0005VK-19 for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 08:59:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Cx3UZ021152 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 08:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A532t-0005V5-Tx for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 08:59:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17046 for ; Thu, 2 Oct 2003 08:58:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A532s-00009e-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 08:59:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A532s-00009b-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 08:59:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A532q-0005TF-Ne; Thu, 02 Oct 2003 08:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A532O-0005Rt-8N for disman@optimus.ietf.org; Thu, 02 Oct 2003 08:58:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16997 for ; Thu, 2 Oct 2003 08:58:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A532M-00008l-00 for disman@ietf.org; Thu, 02 Oct 2003 08:58:30 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A532M-00008R-00 for disman@ietf.org; Thu, 02 Oct 2003 08:58:30 -0400 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h92CvvN14034 for ; Thu, 2 Oct 2003 07:57:57 -0500 (CDT) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 2 Oct 2003 08:57:56 -0400 Message-ID: From: "Lam, Hing-Kam (Kam)" To: "Wijnen, Bert (Bert)" , "'Disman (E-mail) (E-mail)'" Cc: "'Ted Hardie (E-mail)'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [Disman] RE: Another IESG comment - pls respond ASAP 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, 2 Oct 2003 08:57:55 -0400 Thanks for the comment. I will propose the following to highlight the design. In Section 4 "ARC MIB Overview", add the following text as a new paragraph after the 5th paragraph (The 5th paragraph is the one starts with the sentence: This document defines ....) Defined in M.3100 Amendment 3 [M.3100 Amd3], there are five ARC states: alm, nalm, nalmQI, nalmQICD and nalmTI. In the ARC MIB module, the arcState object is defined to model the M.3100 ARC states. Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., into the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. Regards, Kam > -----Original Message----- > From: Wijnen, Bert (Bert) > Sent: Thursday, October 02, 2003 6:35 AM > To: Lam, Hing-Kam (Kam); Disman (E-mail) (E-mail) > Cc: Ted Hardie (E-mail) > Subject: Another IESG comment - pls respond ASAP > > > WG/Authors/editors, dow we want to do something > about the following: > > Ted Hardie: > Buried in the ARCState description is: > > " Note that the state alm (alarm reporting is allowed) is not listed > in the enumeration of the value of this object. However, this > state is implicitly supported by the mib. > Once a resource enters the normal reporting mode (i.e., > in the alm > state) for the specified alarm type, the corresponding > row will be automatically deleted from the arc table. > Also the manual setting of arcState to alm can be achieved through > setting the RowStatus object to 'destroy'. > > This seems a major enough design decision on how to accomplish > the work to move it into the text of the document or repeat > it there. > > Thanks, > Bert > From disman-admin@ietf.org Thu Oct 2 09:15: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 JAA17672 for ; Thu, 2 Oct 2003 09:15:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A53IN-0006f2-GJ; Thu, 02 Oct 2003 09:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A53IF-0006eF-A1 for disman@optimus.ietf.org; Thu, 02 Oct 2003 09:14:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17631 for ; Thu, 2 Oct 2003 09:14:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A53ID-0000M3-00 for disman@ietf.org; Thu, 02 Oct 2003 09:14:53 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A53IC-0000L1-00 for disman@ietf.org; Thu, 02 Oct 2003 09:14:52 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h92DF0k09068 for ; Thu, 2 Oct 2003 08:15:00 -0500 (CDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 2 Oct 2003 09:14:18 -0400 Message-ID: From: "Lam, Hing-Kam (Kam)" To: "'Randy Presuhn'" , "Disman (E-mail)" Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm M IB MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 2 Oct 2003 09:14:17 -0400 Sharon, Also inform SG4 about the current status of the I-D and provide the URL of the latest version. --Kam > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Wednesday, October 01, 2003 4:23 PM > To: Disman (E-mail) > Subject: Re: [Disman] Draft Response to Liaison from ITU-T SG > 4 on Alarm > MIB > > > Hi - > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Wednesday, October 01, 2003 9:58 AM > > Subject: [Disman] Draft Response to Liaison from ITU-T SG 4 > on Alarm MIB > ... > > I took an action out of IETF 56 to draft a response to the > liaison from > > ITU-T Study Group 4 on Alarm MIB. As the next SG 4 meeting > starts on October > > 27th, I figured I should finally take a crack at that. We > agreed on the > > spirit of this text when we last met as a working group. Here goes: > > Let's use > http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt > as our guide for form and process, and inform its authors if > we run into > any problems. So, let's at least include the necessary > boilerplate items. > > > "Thank you for the interest in the Alarm MIB. The > Distributed Management > > (disman) working group hopes to advance the current I-D to Proposed > > Standard, with minimal editorial changes. In the future, if > the working > > group is chartered with an Alarm MIB version 2, we will be > interested in > > cooperating with you to ensure your requirements are considered." > > I'd like to make it clear that (as far as I know) we've > addressed all their > comments. Regarding possible future work, I'd prefer a > broader statement. > How about "We welcome your input on any disman work items, including > discussions of possible future work"? > > > When we agree on the text, did you want me to get it to SG > 4 or did we want > > to follow another path? > ... > > Let's see how > http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt > works. > > Randy Presuhn, disman WG chair > > > From exim@www1.ietf.org Thu Oct 2 09:15: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 JAA17687 for ; Thu, 2 Oct 2003 09:15:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A53IP-0006fr-JA for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 09:15:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92DF5MC025649 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 09:15:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A53IP-0006fc-F2 for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 09:15:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17648 for ; Thu, 2 Oct 2003 09:14:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A53IN-0000MT-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 09:15:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A53IN-0000MQ-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 09:15:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A53IN-0006f2-GJ; Thu, 02 Oct 2003 09:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A53IF-0006eF-A1 for disman@optimus.ietf.org; Thu, 02 Oct 2003 09:14:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17631 for ; Thu, 2 Oct 2003 09:14:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A53ID-0000M3-00 for disman@ietf.org; Thu, 02 Oct 2003 09:14:53 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A53IC-0000L1-00 for disman@ietf.org; Thu, 02 Oct 2003 09:14:52 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h92DF0k09068 for ; Thu, 2 Oct 2003 08:15:00 -0500 (CDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 2 Oct 2003 09:14:18 -0400 Message-ID: From: "Lam, Hing-Kam (Kam)" To: "'Randy Presuhn'" , "Disman (E-mail)" Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm M IB MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 2 Oct 2003 09:14:17 -0400 Sharon, Also inform SG4 about the current status of the I-D and provide the URL of the latest version. --Kam > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Wednesday, October 01, 2003 4:23 PM > To: Disman (E-mail) > Subject: Re: [Disman] Draft Response to Liaison from ITU-T SG > 4 on Alarm > MIB > > > Hi - > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Wednesday, October 01, 2003 9:58 AM > > Subject: [Disman] Draft Response to Liaison from ITU-T SG 4 > on Alarm MIB > ... > > I took an action out of IETF 56 to draft a response to the > liaison from > > ITU-T Study Group 4 on Alarm MIB. As the next SG 4 meeting > starts on October > > 27th, I figured I should finally take a crack at that. We > agreed on the > > spirit of this text when we last met as a working group. Here goes: > > Let's use > http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt > as our guide for form and process, and inform its authors if > we run into > any problems. So, let's at least include the necessary > boilerplate items. > > > "Thank you for the interest in the Alarm MIB. The > Distributed Management > > (disman) working group hopes to advance the current I-D to Proposed > > Standard, with minimal editorial changes. In the future, if > the working > > group is chartered with an Alarm MIB version 2, we will be > interested in > > cooperating with you to ensure your requirements are considered." > > I'd like to make it clear that (as far as I know) we've > addressed all their > comments. Regarding possible future work, I'd prefer a > broader statement. > How about "We welcome your input on any disman work items, including > discussions of possible future work"? > > > When we agree on the text, did you want me to get it to SG > 4 or did we want > > to follow another path? > ... > > Let's see how > http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt > works. > > Randy Presuhn, disman WG chair > > > From disman-admin@ietf.org Thu Oct 2 12:31: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 MAA29572 for ; Thu, 2 Oct 2003 12:31:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56M1-00021S-TD; Thu, 02 Oct 2003 12:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56LA-000207-AJ for disman@optimus.ietf.org; Thu, 02 Oct 2003 12:30:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29515 for ; Thu, 2 Oct 2003 12:29:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56L8-0003D6-00 for disman@ietf.org; Thu, 02 Oct 2003 12:30:06 -0400 Received: from grouse.mail.pas.earthlink.net ([207.217.120.116]) by ietf-mx with esmtp (Exim 4.12) id 1A56L8-0003Cz-00 for disman@ietf.org; Thu, 02 Oct 2003 12:30:06 -0400 Received: from h-68-164-76-195.snvacaid.dynamic.covad.net ([68.164.76.195] helo=oemcomputer) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A56L2-0002WW-00 for disman@ietf.org; Thu, 02 Oct 2003 09:30:00 -0700 Message-ID: <002001c38902$6d6855c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] Section 3.1 in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 2 Oct 2003 09:29:32 -0700 Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Thursday, October 02, 2003 12:42 AM > Subject: RE: [Disman] Section 3.1 in draft-ietf-disman-alarm-mib-15.txt ... > > > 12) Page 4: "ITU" acronym should be expanded, for > > > "ITU model" a reference should be given. > > ... > > > > Although this item was marked "Changed", I see there is still > > no reference for "ITU model". Is there a rationale for omitting > > the reference, or was it just an oversight? > > The reference should be to the ITU Alarm MIB in section 5.4 of the same document. ... From exim@www1.ietf.org Thu Oct 2 12:31:28 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 MAA29588 for ; Thu, 2 Oct 2003 12:31:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56M7-000234-RZ for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 12:31:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92GV7VU007868 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 12:31:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56M7-00022p-NQ for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 12:31:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29551 for ; Thu, 2 Oct 2003 12:30:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56M6-0003Dq-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 12:31:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A56M5-0003Dn-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 12:31:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56M1-00021S-TD; Thu, 02 Oct 2003 12:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56LA-000207-AJ for disman@optimus.ietf.org; Thu, 02 Oct 2003 12:30:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29515 for ; Thu, 2 Oct 2003 12:29:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56L8-0003D6-00 for disman@ietf.org; Thu, 02 Oct 2003 12:30:06 -0400 Received: from grouse.mail.pas.earthlink.net ([207.217.120.116]) by ietf-mx with esmtp (Exim 4.12) id 1A56L8-0003Cz-00 for disman@ietf.org; Thu, 02 Oct 2003 12:30:06 -0400 Received: from h-68-164-76-195.snvacaid.dynamic.covad.net ([68.164.76.195] helo=oemcomputer) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A56L2-0002WW-00 for disman@ietf.org; Thu, 02 Oct 2003 09:30:00 -0700 Message-ID: <002001c38902$6d6855c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] Section 3.1 in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 2 Oct 2003 09:29:32 -0700 Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Thursday, October 02, 2003 12:42 AM > Subject: RE: [Disman] Section 3.1 in draft-ietf-disman-alarm-mib-15.txt ... > > > 12) Page 4: "ITU" acronym should be expanded, for > > > "ITU model" a reference should be given. > > ... > > > > Although this item was marked "Changed", I see there is still > > no reference for "ITU model". Is there a rationale for omitting > > the reference, or was it just an oversight? > > The reference should be to the ITU Alarm MIB in section 5.4 of the same document. ... From disman-admin@ietf.org Thu Oct 2 12:33: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 MAA29730 for ; Thu, 2 Oct 2003 12:33:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56Nx-0002L8-8q; Thu, 02 Oct 2003 12:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56NQ-0002Ez-5v for disman@optimus.ietf.org; Thu, 02 Oct 2003 12:32:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29638 for ; Thu, 2 Oct 2003 12:32:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56NO-0003F9-00 for disman@ietf.org; Thu, 02 Oct 2003 12:32:26 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A56NN-0003EM-00 for disman@ietf.org; Thu, 02 Oct 2003 12:32:26 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h92GW5k08841 for ; Thu, 2 Oct 2003 11:32:13 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 2 Oct 2003 18:31:20 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502909C1A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Disman (E-mail) (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [Disman] IESG has approved condition MIB Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 2 Oct 2003 18:31:19 +0200 We just approved it. Formal announcement will come from IESG secretariat in the next few days. We have added these RFC-Editor notes: RFC-Editor Notes: 1.In Section 4 "ARC MIB Overview", add the following text as a new paragraph after the 5th paragraph (The 5th paragraph is the one starts with the sentence: This document defines ....) Defined in M.3100 Amendment 3 [M.3100 Amd3], there are five ARC states: alm, nalm, nalmQI, nalmQICD and nalmTI. In the ARC MIB module, the arcState object is defined to model the M.3100 ARC states. Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., into the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. 2.On page 6, replace DESCRIPTION clause of arcTable with: DESCRIPTION "A table of Alarm Reporting Control (ARC) settings on the system. Alarm Reporting Control is a feature that provides an automatic in-service provisioning capability. Alarm reporting is turned off on a per-resource basis for a selective set of potential alarm conditions to allow sufficient time for customer testing and other maintenance activities in an 'alarm free' state. Once a resource is ready for service, alarm reporting is automatically or manually turned on. Functional description and requirements of Alarm Reporting Control are defined in ITU-T Recommendation M.3100 Amendment 3 [M.3100 Amd3]." 3.On page 9, replace DESCRIPTION clause of arcState with: DESCRIPTION "Defined in M.3100 Amendment 3 [M.3100 Amd3], there are five ARC states: alm, nalm, nalmQI, nalmQICD, and nalmTI. alm: Alarm reporting is turned on (i.e., is allowed). nalm: Alarm reporting is turned off (i.e., not allowed). nalmQI: nalm - Qualified Inhibit. Alarm reporting is turned off until the managed entity is qualified problem-free for an optional persistence interval. Problem-free means that the condition corresponding to the specified alarm type is cleared. nalmQICD: nalmQI - Count down. This is a substate of nalmQI and performs the persistence timing countdown function after the managed entity is qualified problem-free. nalmTI: nalm - Timed Inhibit. Alarm reporting is turned off for a specified time interval. alm may transition to nalm, nalmQI or nalmTI by management request. nalm may transition to alm, nalmQI or nalmTI by management request. nalmQI may transition to nalm or alm by management request. nalmQI may transition to alm automatically if qualified problem-free (if nalmQICD is not supported) or if the CD timer expired (if nalmQICD is supported) nalmTI may transition to alm or nalm by management request. nalmTI may transition to alm automatically if the TI timer expired. Further details of ARC state transitions are defined in Figure 3 of M.3100 Amd3 [M.3100 Amd3]. According to the requirements in M.3100 Amd3, a resource supporting the ARC feature shall support the alm state and at least one of the nalm, nalmTI, and nalmQI states. The nalmQICD state is an optional substate of nalmQI. The arcState object controls the alarm reporting state of a resource. Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., in the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. The nalamQICD state is a transitional state from nalmQI to alm. It is optional depending on the resource type and the implementation of the the resource. If it is supported, before the state transitions from nalmQI to alm, a count down period is activated for a duration set by the object arcNalmCDTimeInterval. When the time is up, the arcState transitions to alm." 4.In security section, page 13, replace this 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 netowrk. with this 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. 5.Please add page numbers to Table of Contents -30-RFC-Editor Notes: 1.In Section 4 "ARC MIB Overview", add the following text as a new paragraph after the 5th paragraph (The 5th paragraph is the one starts with the sentence: This document defines ....) Defined in M.3100 Amendment 3 [M.3100 Amd3], there are five ARC states: alm, nalm, nalmQI, nalmQICD and nalmTI. In the ARC MIB module, the arcState object is defined to model the M.3100 ARC states. Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., into the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. 2.On page 6, replace DESCRIPTION clause of arcTable with: DESCRIPTION "A table of Alarm Reporting Control (ARC) settings on the system. Alarm Reporting Control is a feature that provides an automatic in-service provisioning capability. Alarm reporting is turned off on a per-resource basis for a selective set of potential alarm conditions to allow sufficient time for customer testing and other maintenance activities in an 'alarm free' state. Once a resource is ready for service, alarm reporting is automatically or manually turned on. Functional description and requirements of Alarm Reporting Control are defined in ITU-T Recommendation M.3100 Amendment 3 [M.3100 Amd3]." 3.On page 9, replace DESCRIPTION clause of arcState with: DESCRIPTION "Defined in M.3100 Amendment 3 [M.3100 Amd3], there are five ARC states: alm, nalm, nalmQI, nalmQICD, and nalmTI. alm: Alarm reporting is turned on (i.e., is allowed). nalm: Alarm reporting is turned off (i.e., not allowed). nalmQI: nalm - Qualified Inhibit. Alarm reporting is turned off until the managed entity is qualified problem-free for an optional persistence interval. Problem-free means that the condition corresponding to the specified alarm type is cleared. nalmQICD: nalmQI - Count down. This is a substate of nalmQI and performs the persistence timing countdown function after the managed entity is qualified problem-free. nalmTI: nalm - Timed Inhibit. Alarm reporting is turned off for a specified time interval. alm may transition to nalm, nalmQI or nalmTI by management request. nalm may transition to alm, nalmQI or nalmTI by management request. nalmQI may transition to nalm or alm by management request. nalmQI may transition to alm automatically if qualified problem-free (if nalmQICD is not supported) or if the CD timer expired (if nalmQICD is supported) nalmTI may transition to alm or nalm by management request. nalmTI may transition to alm automatically if the TI timer expired. Further details of ARC state transitions are defined in Figure 3 of M.3100 Amd3 [M.3100 Amd3]. According to the requirements in M.3100 Amd3, a resource supporting the ARC feature shall support the alm state and at least one of the nalm, nalmTI, and nalmQI states. The nalmQICD state is an optional substate of nalmQI. The arcState object controls the alarm reporting state of a resource. Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., in the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. The nalamQICD state is a transitional state from nalmQI to alm. It is optional depending on the resource type and the implementation of the the resource. If it is supported, before the state transitions from nalmQI to alm, a count down period is activated for a duration set by the object arcNalmCDTimeInterval. When the time is up, the arcState transitions to alm." 4.In security section, page 13, replace this 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 netowrk. with this 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. 5.Please add page numbers to Table of Contents Thanks, Bert From exim@www1.ietf.org Thu Oct 2 12:33: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 MAA29748 for ; Thu, 2 Oct 2003 12:33:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56Ny-0002O3-Mv for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 12:33:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92GX2ZE009171 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 12:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56Ny-0002Nq-EP for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 12:33:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29701 for ; Thu, 2 Oct 2003 12:32:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56Nw-0003Fy-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 12:33:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A56Nw-0003Fv-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 12:33:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56Nx-0002L8-8q; Thu, 02 Oct 2003 12:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56NQ-0002Ez-5v for disman@optimus.ietf.org; Thu, 02 Oct 2003 12:32:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29638 for ; Thu, 2 Oct 2003 12:32:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56NO-0003F9-00 for disman@ietf.org; Thu, 02 Oct 2003 12:32:26 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A56NN-0003EM-00 for disman@ietf.org; Thu, 02 Oct 2003 12:32:26 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h92GW5k08841 for ; Thu, 2 Oct 2003 11:32:13 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 2 Oct 2003 18:31:20 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502909C1A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Disman (E-mail) (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [Disman] IESG has approved condition MIB Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 2 Oct 2003 18:31:19 +0200 We just approved it. Formal announcement will come from IESG secretariat in the next few days. We have added these RFC-Editor notes: RFC-Editor Notes: 1.In Section 4 "ARC MIB Overview", add the following text as a new paragraph after the 5th paragraph (The 5th paragraph is the one starts with the sentence: This document defines ....) Defined in M.3100 Amendment 3 [M.3100 Amd3], there are five ARC states: alm, nalm, nalmQI, nalmQICD and nalmTI. In the ARC MIB module, the arcState object is defined to model the M.3100 ARC states. Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., into the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. 2.On page 6, replace DESCRIPTION clause of arcTable with: DESCRIPTION "A table of Alarm Reporting Control (ARC) settings on the system. Alarm Reporting Control is a feature that provides an automatic in-service provisioning capability. Alarm reporting is turned off on a per-resource basis for a selective set of potential alarm conditions to allow sufficient time for customer testing and other maintenance activities in an 'alarm free' state. Once a resource is ready for service, alarm reporting is automatically or manually turned on. Functional description and requirements of Alarm Reporting Control are defined in ITU-T Recommendation M.3100 Amendment 3 [M.3100 Amd3]." 3.On page 9, replace DESCRIPTION clause of arcState with: DESCRIPTION "Defined in M.3100 Amendment 3 [M.3100 Amd3], there are five ARC states: alm, nalm, nalmQI, nalmQICD, and nalmTI. alm: Alarm reporting is turned on (i.e., is allowed). nalm: Alarm reporting is turned off (i.e., not allowed). nalmQI: nalm - Qualified Inhibit. Alarm reporting is turned off until the managed entity is qualified problem-free for an optional persistence interval. Problem-free means that the condition corresponding to the specified alarm type is cleared. nalmQICD: nalmQI - Count down. This is a substate of nalmQI and performs the persistence timing countdown function after the managed entity is qualified problem-free. nalmTI: nalm - Timed Inhibit. Alarm reporting is turned off for a specified time interval. alm may transition to nalm, nalmQI or nalmTI by management request. nalm may transition to alm, nalmQI or nalmTI by management request. nalmQI may transition to nalm or alm by management request. nalmQI may transition to alm automatically if qualified problem-free (if nalmQICD is not supported) or if the CD timer expired (if nalmQICD is supported) nalmTI may transition to alm or nalm by management request. nalmTI may transition to alm automatically if the TI timer expired. Further details of ARC state transitions are defined in Figure 3 of M.3100 Amd3 [M.3100 Amd3]. According to the requirements in M.3100 Amd3, a resource supporting the ARC feature shall support the alm state and at least one of the nalm, nalmTI, and nalmQI states. The nalmQICD state is an optional substate of nalmQI. The arcState object controls the alarm reporting state of a resource. Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., in the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. The nalamQICD state is a transitional state from nalmQI to alm. It is optional depending on the resource type and the implementation of the the resource. If it is supported, before the state transitions from nalmQI to alm, a count down period is activated for a duration set by the object arcNalmCDTimeInterval. When the time is up, the arcState transitions to alm." 4.In security section, page 13, replace this 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 netowrk. with this 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. 5.Please add page numbers to Table of Contents -30-RFC-Editor Notes: 1.In Section 4 "ARC MIB Overview", add the following text as a new paragraph after the 5th paragraph (The 5th paragraph is the one starts with the sentence: This document defines ....) Defined in M.3100 Amendment 3 [M.3100 Amd3], there are five ARC states: alm, nalm, nalmQI, nalmQICD and nalmTI. In the ARC MIB module, the arcState object is defined to model the M.3100 ARC states. Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., into the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. 2.On page 6, replace DESCRIPTION clause of arcTable with: DESCRIPTION "A table of Alarm Reporting Control (ARC) settings on the system. Alarm Reporting Control is a feature that provides an automatic in-service provisioning capability. Alarm reporting is turned off on a per-resource basis for a selective set of potential alarm conditions to allow sufficient time for customer testing and other maintenance activities in an 'alarm free' state. Once a resource is ready for service, alarm reporting is automatically or manually turned on. Functional description and requirements of Alarm Reporting Control are defined in ITU-T Recommendation M.3100 Amendment 3 [M.3100 Amd3]." 3.On page 9, replace DESCRIPTION clause of arcState with: DESCRIPTION "Defined in M.3100 Amendment 3 [M.3100 Amd3], there are five ARC states: alm, nalm, nalmQI, nalmQICD, and nalmTI. alm: Alarm reporting is turned on (i.e., is allowed). nalm: Alarm reporting is turned off (i.e., not allowed). nalmQI: nalm - Qualified Inhibit. Alarm reporting is turned off until the managed entity is qualified problem-free for an optional persistence interval. Problem-free means that the condition corresponding to the specified alarm type is cleared. nalmQICD: nalmQI - Count down. This is a substate of nalmQI and performs the persistence timing countdown function after the managed entity is qualified problem-free. nalmTI: nalm - Timed Inhibit. Alarm reporting is turned off for a specified time interval. alm may transition to nalm, nalmQI or nalmTI by management request. nalm may transition to alm, nalmQI or nalmTI by management request. nalmQI may transition to nalm or alm by management request. nalmQI may transition to alm automatically if qualified problem-free (if nalmQICD is not supported) or if the CD timer expired (if nalmQICD is supported) nalmTI may transition to alm or nalm by management request. nalmTI may transition to alm automatically if the TI timer expired. Further details of ARC state transitions are defined in Figure 3 of M.3100 Amd3 [M.3100 Amd3]. According to the requirements in M.3100 Amd3, a resource supporting the ARC feature shall support the alm state and at least one of the nalm, nalmTI, and nalmQI states. The nalmQICD state is an optional substate of nalmQI. The arcState object controls the alarm reporting state of a resource. Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., in the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. The nalamQICD state is a transitional state from nalmQI to alm. It is optional depending on the resource type and the implementation of the the resource. If it is supported, before the state transitions from nalmQI to alm, a count down period is activated for a duration set by the object arcNalmCDTimeInterval. When the time is up, the arcState transitions to alm." 4.In security section, page 13, replace this 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 netowrk. with this 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. 5.Please add page numbers to Table of Contents Thanks, Bert From disman-admin@ietf.org Thu Oct 2 12:39:22 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 MAA29986 for ; Thu, 2 Oct 2003 12:39:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56Tl-000300-WA; Thu, 02 Oct 2003 12:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56TQ-0002yk-9z for disman@optimus.ietf.org; Thu, 02 Oct 2003 12:38:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29952 for ; Thu, 2 Oct 2003 12:38:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56TO-0003KL-00 for disman@ietf.org; Thu, 02 Oct 2003 12:38:38 -0400 Received: from grouse.mail.pas.earthlink.net ([207.217.120.116]) by ietf-mx with esmtp (Exim 4.12) id 1A56TJ-0003K9-00 for disman@ietf.org; Thu, 02 Oct 2003 12:38:33 -0400 Received: from h-68-164-76-195.snvacaid.dynamic.covad.net ([68.164.76.195] helo=oemcomputer) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A56TI-0007QQ-00 for disman@ietf.org; Thu, 02 Oct 2003 09:38:32 -0700 Message-ID: <002501c38903$9e322720$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 2 Oct 2003 09:38:29 -0700 Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Thursday, October 02, 2003 12:55 AM > Subject: RE: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt ... > > If an SNMPv1 trap had a community string with a value of 0xFF, > what value would the corresponding instance of this object have? > The alarm MIB implementation has no control over the community > strings it might encounter. > > If the alarm's source SNMP engine is known not to support > multiple contexts, this object is a zero length string." > ::= { alarmClearEntry 6 } > > > Is this intended to be a MUST or a MAY? > > Randy ... > The solution is to make the text crisper that community strings can be represented. This means a couple of > MUSTs in the two places quoted by Randy. ... I think this does not solve the problems. In the first case, adding a "MUST" to > "The name of the SNMP MIB context from which the alarm came. > For SNMPv1 traps 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. still doesn't tell us what a system is supposed to do when its handling a trap with a community string of, say, 0xff. In the second case, > If the alarm's source SNMP engine is known not to support > multiple contexts, this object is a zero length string." how is an implementation supposed to know whether a given source doesn't support multiple contexts? For example, in AgentX and SMUX protocols, there is no registration mechanism for notifications, so a master agent has no way of knowing in advance whether it will receive notifications from multiple contexts or not. Randy From exim@www1.ietf.org Thu Oct 2 12:39: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 MAA00005 for ; Thu, 2 Oct 2003 12:39:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56Tn-00030n-4R for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 12:39:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Gd3AY011570 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 12:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56Tn-00030X-0f for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 12:39:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29957 for ; Thu, 2 Oct 2003 12:38:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56Tl-0003KS-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 12:39:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A56Tk-0003KP-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 12:39:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56Tl-000300-WA; Thu, 02 Oct 2003 12:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56TQ-0002yk-9z for disman@optimus.ietf.org; Thu, 02 Oct 2003 12:38:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29952 for ; Thu, 2 Oct 2003 12:38:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56TO-0003KL-00 for disman@ietf.org; Thu, 02 Oct 2003 12:38:38 -0400 Received: from grouse.mail.pas.earthlink.net ([207.217.120.116]) by ietf-mx with esmtp (Exim 4.12) id 1A56TJ-0003K9-00 for disman@ietf.org; Thu, 02 Oct 2003 12:38:33 -0400 Received: from h-68-164-76-195.snvacaid.dynamic.covad.net ([68.164.76.195] helo=oemcomputer) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A56TI-0007QQ-00 for disman@ietf.org; Thu, 02 Oct 2003 09:38:32 -0700 Message-ID: <002501c38903$9e322720$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 2 Oct 2003 09:38:29 -0700 Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Thursday, October 02, 2003 12:55 AM > Subject: RE: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt ... > > If an SNMPv1 trap had a community string with a value of 0xFF, > what value would the corresponding instance of this object have? > The alarm MIB implementation has no control over the community > strings it might encounter. > > If the alarm's source SNMP engine is known not to support > multiple contexts, this object is a zero length string." > ::= { alarmClearEntry 6 } > > > Is this intended to be a MUST or a MAY? > > Randy ... > The solution is to make the text crisper that community strings can be represented. This means a couple of > MUSTs in the two places quoted by Randy. ... I think this does not solve the problems. In the first case, adding a "MUST" to > "The name of the SNMP MIB context from which the alarm came. > For SNMPv1 traps 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. still doesn't tell us what a system is supposed to do when its handling a trap with a community string of, say, 0xff. In the second case, > If the alarm's source SNMP engine is known not to support > multiple contexts, this object is a zero length string." how is an implementation supposed to know whether a given source doesn't support multiple contexts? For example, in AgentX and SMUX protocols, there is no registration mechanism for notifications, so a master agent has no way of knowing in advance whether it will receive notifications from multiple contexts or not. Randy From disman-admin@ietf.org Thu Oct 2 12:44:22 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 MAA00220 for ; Thu, 2 Oct 2003 12:44:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56Yb-0003NT-2l; Thu, 02 Oct 2003 12:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56Y2-0003JU-M4 for disman@optimus.ietf.org; Thu, 02 Oct 2003 12:43:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00160 for ; Thu, 2 Oct 2003 12:43:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56Y0-0003N3-00 for disman@ietf.org; Thu, 02 Oct 2003 12:43:24 -0400 Received: from grouse.mail.pas.earthlink.net ([207.217.120.116]) by ietf-mx with esmtp (Exim 4.12) id 1A56Y0-0003Mu-00 for disman@ietf.org; Thu, 02 Oct 2003 12:43:24 -0400 Received: from h-68-164-76-195.snvacaid.dynamic.covad.net ([68.164.76.195] helo=oemcomputer) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A56Xd-0006Da-00; Thu, 02 Oct 2003 09:43:01 -0700 Message-ID: <003401c38904$3ed7a420$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Wijnen, Bert \(Bert\)" , "Disman \(E-mail\) \(E-mail\)" Cc: "Ted Hardie \(E-mail\)" References: <7D5D48D2CAA3D84C813F5B154F43B155028EC3E4@nl0006exch001u.nl.lucent.com> Subject: Re: [Disman] Another IESG comment - pls respond ASAP 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: Thu, 2 Oct 2003 09:42:54 -0700 Hi - > From: "Wijnen, Bert (Bert)" > To: "Lam, Hing-Kam (Kam)" ; "Disman (E-mail) (E-mail)" > Cc: "Ted Hardie (E-mail)" > Sent: Thursday, October 02, 2003 3:35 AM > Subject: [Disman] Another IESG comment - pls respond ASAP > > WG/Authors/editors, dow we want to do something > about the following: > > Ted Hardie: > Buried in the ARCState description is: > > " Note that the state alm (alarm reporting is allowed) is not listed > in the enumeration of the value of this object. However, this > state is implicitly supported by the mib. > Once a resource enters the normal reporting mode (i.e., in the alm > state) for the specified alarm type, the corresponding > row will be automatically deleted from the arc table. > Also the manual setting of arcState to alm can be achieved through > setting the RowStatus object to 'destroy'. > > This seems a major enough design decision on how to accomplish > the work to move it into the text of the document or repeat it there. > > Thanks, > Bert As a technical contributor, I have no problem with repeating it in the text of the document. I think it would be a mistake to move it. Randy From exim@www1.ietf.org Thu Oct 2 12:44: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 MAA00238 for ; Thu, 2 Oct 2003 12:44:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56Yd-0003P8-Fp for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 12:44:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Gi3K7013080 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 12:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56Yd-0003Ot-BF for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 12:44:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00203 for ; Thu, 2 Oct 2003 12:43:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56Yb-0003Np-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 12:44:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A56Yb-0003Nm-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 12:44:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56Yb-0003NT-2l; Thu, 02 Oct 2003 12:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56Y2-0003JU-M4 for disman@optimus.ietf.org; Thu, 02 Oct 2003 12:43:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00160 for ; Thu, 2 Oct 2003 12:43:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56Y0-0003N3-00 for disman@ietf.org; Thu, 02 Oct 2003 12:43:24 -0400 Received: from grouse.mail.pas.earthlink.net ([207.217.120.116]) by ietf-mx with esmtp (Exim 4.12) id 1A56Y0-0003Mu-00 for disman@ietf.org; Thu, 02 Oct 2003 12:43:24 -0400 Received: from h-68-164-76-195.snvacaid.dynamic.covad.net ([68.164.76.195] helo=oemcomputer) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A56Xd-0006Da-00; Thu, 02 Oct 2003 09:43:01 -0700 Message-ID: <003401c38904$3ed7a420$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Wijnen, Bert \(Bert\)" , "Disman \(E-mail\) \(E-mail\)" Cc: "Ted Hardie \(E-mail\)" References: <7D5D48D2CAA3D84C813F5B154F43B155028EC3E4@nl0006exch001u.nl.lucent.com> Subject: Re: [Disman] Another IESG comment - pls respond ASAP 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: Thu, 2 Oct 2003 09:42:54 -0700 Hi - > From: "Wijnen, Bert (Bert)" > To: "Lam, Hing-Kam (Kam)" ; "Disman (E-mail) (E-mail)" > Cc: "Ted Hardie (E-mail)" > Sent: Thursday, October 02, 2003 3:35 AM > Subject: [Disman] Another IESG comment - pls respond ASAP > > WG/Authors/editors, dow we want to do something > about the following: > > Ted Hardie: > Buried in the ARCState description is: > > " Note that the state alm (alarm reporting is allowed) is not listed > in the enumeration of the value of this object. However, this > state is implicitly supported by the mib. > Once a resource enters the normal reporting mode (i.e., in the alm > state) for the specified alarm type, the corresponding > row will be automatically deleted from the arc table. > Also the manual setting of arcState to alm can be achieved through > setting the RowStatus object to 'destroy'. > > This seems a major enough design decision on how to accomplish > the work to move it into the text of the document or repeat it there. > > Thanks, > Bert As a technical contributor, I have no problem with repeating it in the text of the document. I think it would be a mistake to move it. Randy From disman-admin@ietf.org Thu Oct 2 12:46: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 MAA00335 for ; Thu, 2 Oct 2003 12:46:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56aX-0003d2-7t; Thu, 02 Oct 2003 12:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56Zv-0003Yj-DU for disman@optimus.ietf.org; Thu, 02 Oct 2003 12:45:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00288 for ; Thu, 2 Oct 2003 12:45:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56Zt-0003PV-00 for disman@ietf.org; Thu, 02 Oct 2003 12:45:21 -0400 Received: from grouse.mail.pas.earthlink.net ([207.217.120.116]) by ietf-mx with esmtp (Exim 4.12) id 1A56Zs-0003PS-00 for disman@ietf.org; Thu, 02 Oct 2003 12:45:21 -0400 Received: from h-68-164-76-195.snvacaid.dynamic.covad.net ([68.164.76.195] helo=oemcomputer) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A56Zn-00027E-00 for disman@ietf.org; Thu, 02 Oct 2003 09:45:15 -0700 Message-ID: <003901c38904$8e871dc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] draft-ietf-disman-conditionmib 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: Thu, 2 Oct 2003 09:45:14 -0700 Hi - > From: "Lam, Hing-Kam (Kam)" > To: "Wijnen, Bert (Bert)" ; "Disman (E-mail) (E-mail)" > Sent: Thursday, October 02, 2003 5:43 AM > Subject: RE: [Disman] draft-ietf-disman-conditionmib > > Okay. Consolidate the ARC state definition and transition into the > DESCRIPTION clause of the arcState object as follow. > Thanks. ... Looks ok to me. Randy From exim@www1.ietf.org Thu Oct 2 12:46:22 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 MAA00350 for ; Thu, 2 Oct 2003 12:46:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56aY-0003dt-JO for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 12:46:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Gk2e7013995 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 12:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56aY-0003de-Ex for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 12:46:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00320 for ; Thu, 2 Oct 2003 12:45:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56aW-0003Pq-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 12:46:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A56aW-0003Pn-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 12:46:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56aX-0003d2-7t; Thu, 02 Oct 2003 12:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56Zv-0003Yj-DU for disman@optimus.ietf.org; Thu, 02 Oct 2003 12:45:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00288 for ; Thu, 2 Oct 2003 12:45:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56Zt-0003PV-00 for disman@ietf.org; Thu, 02 Oct 2003 12:45:21 -0400 Received: from grouse.mail.pas.earthlink.net ([207.217.120.116]) by ietf-mx with esmtp (Exim 4.12) id 1A56Zs-0003PS-00 for disman@ietf.org; Thu, 02 Oct 2003 12:45:21 -0400 Received: from h-68-164-76-195.snvacaid.dynamic.covad.net ([68.164.76.195] helo=oemcomputer) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A56Zn-00027E-00 for disman@ietf.org; Thu, 02 Oct 2003 09:45:15 -0700 Message-ID: <003901c38904$8e871dc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] draft-ietf-disman-conditionmib 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: Thu, 2 Oct 2003 09:45:14 -0700 Hi - > From: "Lam, Hing-Kam (Kam)" > To: "Wijnen, Bert (Bert)" ; "Disman (E-mail) (E-mail)" > Sent: Thursday, October 02, 2003 5:43 AM > Subject: RE: [Disman] draft-ietf-disman-conditionmib > > Okay. Consolidate the ARC state definition and transition into the > DESCRIPTION clause of the arcState object as follow. > Thanks. ... Looks ok to me. Randy From disman-admin@ietf.org Thu Oct 2 12:57: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 MAA00717 for ; Thu, 2 Oct 2003 12:57:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56lA-0004BI-Hd; Thu, 02 Oct 2003 12:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56kl-0004Ao-Li for disman@optimus.ietf.org; Thu, 02 Oct 2003 12:56:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00672 for ; Thu, 2 Oct 2003 12:56:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56kf-0003Vy-00 for disman@ietf.org; Thu, 02 Oct 2003 12:56:29 -0400 Received: from grouse.mail.pas.earthlink.net ([207.217.120.116]) by ietf-mx with esmtp (Exim 4.12) id 1A56ke-0003Vv-00 for disman@ietf.org; Thu, 02 Oct 2003 12:56:28 -0400 Received: from h-68-164-76-195.snvacaid.dynamic.covad.net ([68.164.76.195] helo=oemcomputer) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A56kZ-0003ZU-00 for disman@ietf.org; Thu, 02 Oct 2003 09:56:23 -0700 Message-ID: <005101c38906$1cf2f740$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <7D5D48D2CAA3D84C813F5B154F43B15502909C1A@nl0006exch001u.nl.lucent.com> Subject: Re: [Disman] IESG has approved condition MIB X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 2 Oct 2003 09:56:10 -0700 Hi - > From: "Wijnen, Bert (Bert)" > To: "Disman (E-mail) (E-mail)" > Sent: Thursday, October 02, 2003 9:31 AM > Subject: [Disman] IESG has approved condition MIB > > We just approved it. Formal announcement will come from > IESG secretariat in the next few days. Congratulations to everyone who has helped in getting this far! This is taken longer than any of us would have liked, but will be a bit of good news to include in the SG4 liaison. > We have added these RFC-Editor notes: ... Kam, when AUTH48 rolls around, please check to ensure that nothing was broken by the application of these notes. Randy From exim@www1.ietf.org Thu Oct 2 12:57:22 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 MAA00733 for ; Thu, 2 Oct 2003 12:57:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56lC-0004C8-9p for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 12:57:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Gv2n8016118 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 12:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56lC-0004Bt-4C for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 12:57:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00706 for ; Thu, 2 Oct 2003 12:56:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56lA-0003WJ-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 12:57:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A56l9-0003WG-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 12:56:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56lA-0004BI-Hd; Thu, 02 Oct 2003 12:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56kl-0004Ao-Li for disman@optimus.ietf.org; Thu, 02 Oct 2003 12:56:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00672 for ; Thu, 2 Oct 2003 12:56:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56kf-0003Vy-00 for disman@ietf.org; Thu, 02 Oct 2003 12:56:29 -0400 Received: from grouse.mail.pas.earthlink.net ([207.217.120.116]) by ietf-mx with esmtp (Exim 4.12) id 1A56ke-0003Vv-00 for disman@ietf.org; Thu, 02 Oct 2003 12:56:28 -0400 Received: from h-68-164-76-195.snvacaid.dynamic.covad.net ([68.164.76.195] helo=oemcomputer) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A56kZ-0003ZU-00 for disman@ietf.org; Thu, 02 Oct 2003 09:56:23 -0700 Message-ID: <005101c38906$1cf2f740$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <7D5D48D2CAA3D84C813F5B154F43B15502909C1A@nl0006exch001u.nl.lucent.com> Subject: Re: [Disman] IESG has approved condition MIB X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 2 Oct 2003 09:56:10 -0700 Hi - > From: "Wijnen, Bert (Bert)" > To: "Disman (E-mail) (E-mail)" > Sent: Thursday, October 02, 2003 9:31 AM > Subject: [Disman] IESG has approved condition MIB > > We just approved it. Formal announcement will come from > IESG secretariat in the next few days. Congratulations to everyone who has helped in getting this far! This is taken longer than any of us would have liked, but will be a bit of good news to include in the SG4 liaison. > We have added these RFC-Editor notes: ... Kam, when AUTH48 rolls around, please check to ensure that nothing was broken by the application of these notes. Randy From disman-admin@ietf.org Thu Oct 2 13:23:28 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 NAA14539 for ; Thu, 2 Oct 2003 13:23:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57AK-00054W-UA; Thu, 02 Oct 2003 13:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A579x-000520-Pq for disman@optimus.ietf.org; Thu, 02 Oct 2003 13:22:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14498 for ; Thu, 2 Oct 2003 13:22:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A579v-0003l8-00 for disman@ietf.org; Thu, 02 Oct 2003 13:22:35 -0400 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1A579v-0003l5-00 for disman@ietf.org; Thu, 02 Oct 2003 13:22:35 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h92HMEiS017436 for ; Thu, 2 Oct 2003 13:22:14 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h92HMBiS017424 for ; Thu, 2 Oct 2003 13:22:12 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt Message-ID: Thread-Topic: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOJA7ZWe35vXBqsTWqQgxluq0t6LwABXpRw 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: Thu, 2 Oct 2003 20:22:32 +0300 Content-Transfer-Encoding: quoted-printable See in-line. Regards, Dan > > > > If an SNMPv1 trap had a community string with a value of 0xFF, > > what value would the corresponding instance of this object have? > > The alarm MIB implementation has no control over the community > > strings it might encounter. > > > > If the alarm's source SNMP engine is known not to support > > multiple contexts, this object is a zero length string." > > ::=3D { alarmClearEntry 6 } > > > > > > Is this intended to be a MUST or a MAY? > > > > Randy >=20 > ... > > The solution is to make the text crisper that community=20 > strings can be represented. This means a couple of > > MUSTs in the two places quoted by Randy. > ... >=20 > I think this does not solve the problems. > In the first case, adding a "MUST" to >=20 > > "The name of the SNMP MIB context from which the=20 > alarm came. > > For SNMPv1 traps this is the community string=20 > 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. >=20 > still doesn't tell us what a system is supposed to do when=20 > 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. >=20 > In the second case, > > If the alarm's source SNMP engine is known not to support > > multiple contexts, this object is a zero length string." >=20 > how is an implementation supposed to know whether a given source > doesn't support multiple contexts? For example, in AgentX and > SMUX protocols, there is no registration mechanism for notifications, > so a master agent has no way of knowing in advance whether it will > receive notifications from multiple contexts or not. >=20 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? > Randy >=20 >=20 >=20 >=20 From exim@www1.ietf.org Thu Oct 2 13:23:29 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 NAA14554 for ; Thu, 2 Oct 2003 13:23:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57AS-00056D-Oj for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 13:23:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92HN8s2019595 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 13:23:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57AS-00055y-L4 for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 13:23:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14511 for ; Thu, 2 Oct 2003 13:22:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A57AQ-0003lV-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 13:23:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A57AQ-0003lS-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 13:23:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57AK-00054W-UA; Thu, 02 Oct 2003 13:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A579x-000520-Pq for disman@optimus.ietf.org; Thu, 02 Oct 2003 13:22:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14498 for ; Thu, 2 Oct 2003 13:22:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A579v-0003l8-00 for disman@ietf.org; Thu, 02 Oct 2003 13:22:35 -0400 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1A579v-0003l5-00 for disman@ietf.org; Thu, 02 Oct 2003 13:22:35 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h92HMEiS017436 for ; Thu, 2 Oct 2003 13:22:14 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h92HMBiS017424 for ; Thu, 2 Oct 2003 13:22:12 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt Message-ID: Thread-Topic: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOJA7ZWe35vXBqsTWqQgxluq0t6LwABXpRw 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: Thu, 2 Oct 2003 20:22:32 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable See in-line. Regards, Dan > > > > If an SNMPv1 trap had a community string with a value of 0xFF, > > what value would the corresponding instance of this object have? > > The alarm MIB implementation has no control over the community > > strings it might encounter. > > > > If the alarm's source SNMP engine is known not to support > > multiple contexts, this object is a zero length string." > > ::=3D { alarmClearEntry 6 } > > > > > > Is this intended to be a MUST or a MAY? > > > > Randy >=20 > ... > > The solution is to make the text crisper that community=20 > strings can be represented. This means a couple of > > MUSTs in the two places quoted by Randy. > ... >=20 > I think this does not solve the problems. > In the first case, adding a "MUST" to >=20 > > "The name of the SNMP MIB context from which the=20 > alarm came. > > For SNMPv1 traps this is the community string=20 > 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. >=20 > still doesn't tell us what a system is supposed to do when=20 > 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. >=20 > In the second case, > > If the alarm's source SNMP engine is known not to support > > multiple contexts, this object is a zero length string." >=20 > how is an implementation supposed to know whether a given source > doesn't support multiple contexts? For example, in AgentX and > SMUX protocols, there is no registration mechanism for notifications, > so a master agent has no way of knowing in advance whether it will > receive notifications from multiple contexts or not. >=20 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? > Randy >=20 >=20 >=20 >=20 From disman-admin@ietf.org Thu Oct 2 13:39: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 NAA15399 for ; Thu, 2 Oct 2003 13:39:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57Po-0006Zy-Eu; Thu, 02 Oct 2003 13:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57PJ-0006ZW-Go for disman@optimus.ietf.org; Thu, 02 Oct 2003 13:38:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15333 for ; Thu, 2 Oct 2003 13:38:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A57PH-0003xo-00 for disman@ietf.org; Thu, 02 Oct 2003 13:38:27 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1A57PG-0003xl-00 for disman@ietf.org; Thu, 02 Oct 2003 13:38:26 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h92HaaJK022657 for ; Thu, 2 Oct 2003 12:36:36 -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 h92HaTJK022590 for ; Thu, 2 Oct 2003 12:36:34 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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 3.1 in draft-ietf-disman-alarm-mib-15.txt Message-ID: Thread-Topic: [Disman] Section 3.1 in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOJAp1PpL499kkoQJKx1HbK/smJoQACSJkQ 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: Thu, 2 Oct 2003 20:38:17 +0300 Content-Transfer-Encoding: quoted-printable Section 5.4 references M.3100 and X.733 explicitly. However, the 'model' = concept is used through the document, with the ITU Model described in = 5.4 as primary example. Regards, Dan > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: 02 October, 2003 7:30 PM > To: Disman (E-mail) > Subject: Re: [Disman] Section 3.1 in=20 > draft-ietf-disman-alarm-mib-15.txt >=20 >=20 > Hi - >=20 > > From: "Romascanu, Dan (Dan)" > > To: "Randy Presuhn" ; "Disman=20 > (E-mail)" > > Sent: Thursday, October 02, 2003 12:42 AM > > Subject: RE: [Disman] Section 3.1 in=20 > draft-ietf-disman-alarm-mib-15.txt > ... > > > > 12) Page 4: "ITU" acronym should be expanded, for > > > > "ITU model" a reference should be given. > > > ... > > > > > > Although this item was marked "Changed", I see there is still > > > no reference for "ITU model". Is there a rationale for omitting > > > the reference, or was it just an oversight? > > > > The reference should be to the ITU Alarm MIB in section 5.4=20 > of the same document. > ... >=20 > From the context, I thought it was talking about M.3100 or X.733. > I wouldn't have thought to look for an ITU model in an IETF document. > I guess this demonstrates the value of being explicit. >=20 > Randy >=20 >=20 >=20 >=20 >=20 From exim@www1.ietf.org Thu Oct 2 13:39:28 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 NAA15417 for ; Thu, 2 Oct 2003 13:39:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57Pu-0006b8-T6 for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 13:39:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Hd6k8025356 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 13:39:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57Pu-0006at-Pp for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 13:39:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15384 for ; Thu, 2 Oct 2003 13:38:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A57Ps-0003yP-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 13:39:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A57Ps-0003yM-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 13:39:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57Po-0006Zy-Eu; Thu, 02 Oct 2003 13:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57PJ-0006ZW-Go for disman@optimus.ietf.org; Thu, 02 Oct 2003 13:38:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15333 for ; Thu, 2 Oct 2003 13:38:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A57PH-0003xo-00 for disman@ietf.org; Thu, 02 Oct 2003 13:38:27 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1A57PG-0003xl-00 for disman@ietf.org; Thu, 02 Oct 2003 13:38:26 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h92HaaJK022657 for ; Thu, 2 Oct 2003 12:36:36 -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 h92HaTJK022590 for ; Thu, 2 Oct 2003 12:36:34 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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 3.1 in draft-ietf-disman-alarm-mib-15.txt Message-ID: Thread-Topic: [Disman] Section 3.1 in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOJAp1PpL499kkoQJKx1HbK/smJoQACSJkQ 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: Thu, 2 Oct 2003 20:38:17 +0300 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Section 5.4 references M.3100 and X.733 explicitly. However, the 'model' = concept is used through the document, with the ITU Model described in = 5.4 as primary example. Regards, Dan > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: 02 October, 2003 7:30 PM > To: Disman (E-mail) > Subject: Re: [Disman] Section 3.1 in=20 > draft-ietf-disman-alarm-mib-15.txt >=20 >=20 > Hi - >=20 > > From: "Romascanu, Dan (Dan)" > > To: "Randy Presuhn" ; "Disman=20 > (E-mail)" > > Sent: Thursday, October 02, 2003 12:42 AM > > Subject: RE: [Disman] Section 3.1 in=20 > draft-ietf-disman-alarm-mib-15.txt > ... > > > > 12) Page 4: "ITU" acronym should be expanded, for > > > > "ITU model" a reference should be given. > > > ... > > > > > > Although this item was marked "Changed", I see there is still > > > no reference for "ITU model". Is there a rationale for omitting > > > the reference, or was it just an oversight? > > > > The reference should be to the ITU Alarm MIB in section 5.4=20 > of the same document. > ... >=20 > From the context, I thought it was talking about M.3100 or X.733. > I wouldn't have thought to look for an ITU model in an IETF document. > I guess this demonstrates the value of being explicit. >=20 > Randy >=20 >=20 >=20 >=20 >=20 From disman-admin@ietf.org Thu Oct 2 16:13:32 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 QAA23701 for ; Thu, 2 Oct 2003 16:13:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A59or-0007c4-Fd; Thu, 02 Oct 2003 16:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A59o0-0007b0-My for disman@optimus.ietf.org; Thu, 02 Oct 2003 16:12:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23655 for ; Thu, 2 Oct 2003 16:11:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A59ny-00066m-00 for disman@ietf.org; Thu, 02 Oct 2003 16:12:06 -0400 Received: from gull.mail.pas.earthlink.net ([207.217.120.84]) by ietf-mx with esmtp (Exim 4.12) id 1A59ny-00066j-00 for disman@ietf.org; Thu, 02 Oct 2003 16:12:06 -0400 Received: from h-68-164-29-208.snvacaid.dynamic.covad.net ([68.164.29.208] helo=oemcomputer) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A59nx-0000i8-00 for disman@ietf.org; Thu, 02 Oct 2003 13:12:05 -0700 Message-ID: <000401c38921$73adc540$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 2 Oct 2003 13:12:05 -0700 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 Thu Oct 2 16:13:33 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 QAA23716 for ; Thu, 2 Oct 2003 16:13:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A59p2-0007k2-24 for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 16:13:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92KDC2s029752 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 16:13:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A59p1-0007jn-UY for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 16:13:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23680 for ; Thu, 2 Oct 2003 16:13:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A59p0-00067K-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 16:13:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A59oz-00067H-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 16:13:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A59or-0007c4-Fd; Thu, 02 Oct 2003 16:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A59o0-0007b0-My for disman@optimus.ietf.org; Thu, 02 Oct 2003 16:12:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23655 for ; Thu, 2 Oct 2003 16:11:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A59ny-00066m-00 for disman@ietf.org; Thu, 02 Oct 2003 16:12:06 -0400 Received: from gull.mail.pas.earthlink.net ([207.217.120.84]) by ietf-mx with esmtp (Exim 4.12) id 1A59ny-00066j-00 for disman@ietf.org; Thu, 02 Oct 2003 16:12:06 -0400 Received: from h-68-164-29-208.snvacaid.dynamic.covad.net ([68.164.29.208] helo=oemcomputer) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A59nx-0000i8-00 for disman@ietf.org; Thu, 02 Oct 2003 13:12:05 -0700 Message-ID: <000401c38921$73adc540$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 2 Oct 2003 13:12:05 -0700 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 Thu Oct 2 18:32: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 SAA29236 for ; Thu, 2 Oct 2003 18:32:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5BzN-0006uA-98; Thu, 02 Oct 2003 18:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Bz3-0006td-5I for disman@optimus.ietf.org; Thu, 02 Oct 2003 18:31:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29204 for ; Thu, 2 Oct 2003 18:31:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Byz-0007bw-00 for disman@ietf.org; Thu, 02 Oct 2003 18:31:37 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A5Byz-0007bt-00 for disman@ietf.org; Thu, 02 Oct 2003 18:31:37 -0400 Received: from h-68-164-29-208.snvacaid.dynamic.covad.net ([68.164.29.208] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5Byx-0004no-00 for disman@ietf.org; Thu, 02 Oct 2003 15:31:35 -0700 Message-ID: <001f01c38934$f0d80720$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] Section 5.1 in draft-ietf-disman-alarm-mib-15.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, 2 Oct 2003 15:31:36 -0700 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 ... > 65) 5.1: "about alarms" -> "about alarms modeled using the ituAlarmTable" > "total alarms" -> "total alarms modeled using the ituAlarmTable" ... Though this item is identified as "changed", it looks like it only got half done. As it stands, I think this sentence is still incorrect: The ituAlarmActiveStatsTable provides statistics on current and total alarms. The number is the total for stuff modeled using the ituAlarmTable, not total alarms in the system, right? Randy From exim@www1.ietf.org Thu Oct 2 18:32: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 SAA29251 for ; Thu, 2 Oct 2003 18:32:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5BzU-0006uw-4r for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 18:32:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92MW89V026587 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 18:32:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5BzT-0006uk-Vu for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 18:32:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29213 for ; Thu, 2 Oct 2003 18:31:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5BzQ-0007cX-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 18:32:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5BzQ-0007cU-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 18:32:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5BzN-0006uA-98; Thu, 02 Oct 2003 18:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Bz3-0006td-5I for disman@optimus.ietf.org; Thu, 02 Oct 2003 18:31:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29204 for ; Thu, 2 Oct 2003 18:31:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Byz-0007bw-00 for disman@ietf.org; Thu, 02 Oct 2003 18:31:37 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A5Byz-0007bt-00 for disman@ietf.org; Thu, 02 Oct 2003 18:31:37 -0400 Received: from h-68-164-29-208.snvacaid.dynamic.covad.net ([68.164.29.208] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5Byx-0004no-00 for disman@ietf.org; Thu, 02 Oct 2003 15:31:35 -0700 Message-ID: <001f01c38934$f0d80720$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] Section 5.1 in draft-ietf-disman-alarm-mib-15.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, 2 Oct 2003 15:31:36 -0700 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 ... > 65) 5.1: "about alarms" -> "about alarms modeled using the ituAlarmTable" > "total alarms" -> "total alarms modeled using the ituAlarmTable" ... Though this item is identified as "changed", it looks like it only got half done. As it stands, I think this sentence is still incorrect: The ituAlarmActiveStatsTable provides statistics on current and total alarms. The number is the total for stuff modeled using the ituAlarmTable, not total alarms in the system, right? Randy From disman-admin@ietf.org Thu Oct 2 18:42: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 SAA29507 for ; Thu, 2 Oct 2003 18:42:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5C92-0007V0-T2; Thu, 02 Oct 2003 18:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5C8v-0007Un-ET for disman@optimus.ietf.org; Thu, 02 Oct 2003 18:41:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29494 for ; Thu, 2 Oct 2003 18:41:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5C8g-0007hG-00 for disman@ietf.org; Thu, 02 Oct 2003 18:41:38 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A5C8f-0007hD-00 for disman@ietf.org; Thu, 02 Oct 2003 18:41:37 -0400 Received: from h-68-164-29-208.snvacaid.dynamic.covad.net ([68.164.29.208] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5C8f-0005bx-00 for disman@ietf.org; Thu, 02 Oct 2003 15:41:37 -0700 Message-ID: <002301c38936$57bf4ce0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] IANA considerations in draft-ietf-disman-alarm-mib-15.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, 2 Oct 2003 15:41:38 -0700 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 > ... > 66) 5.2: we will probably need to give IANA more guidance on how additions > should be approved. We agreed that we didn't want an immortal WG, but > we do need to tell them what kind of review, if any, is needed before > a addition is made. ... Though this is marked "changed", I can't find a statement about what kind of review is needed for additions. I think RFC 2434 section 4 is pretty clear that this is needed. I propose the "specification required" level of review. Other thoughts? Randy From exim@www1.ietf.org Thu Oct 2 18:42: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 SAA29525 for ; Thu, 2 Oct 2003 18:42:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5C94-0007Vm-JV for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 18:42:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Mg2c1028860 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 18:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5C93-0007VP-SP for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 18:42:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29499 for ; Thu, 2 Oct 2003 18:41:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5C90-0007hM-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 18:41:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5C90-0007hJ-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 18:41:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5C92-0007V0-T2; Thu, 02 Oct 2003 18:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5C8v-0007Un-ET for disman@optimus.ietf.org; Thu, 02 Oct 2003 18:41:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29494 for ; Thu, 2 Oct 2003 18:41:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5C8g-0007hG-00 for disman@ietf.org; Thu, 02 Oct 2003 18:41:38 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A5C8f-0007hD-00 for disman@ietf.org; Thu, 02 Oct 2003 18:41:37 -0400 Received: from h-68-164-29-208.snvacaid.dynamic.covad.net ([68.164.29.208] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5C8f-0005bx-00 for disman@ietf.org; Thu, 02 Oct 2003 15:41:37 -0700 Message-ID: <002301c38936$57bf4ce0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] IANA considerations in draft-ietf-disman-alarm-mib-15.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, 2 Oct 2003 15:41:38 -0700 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 > ... > 66) 5.2: we will probably need to give IANA more guidance on how additions > should be approved. We agreed that we didn't want an immortal WG, but > we do need to tell them what kind of review, if any, is needed before > a addition is made. ... Though this is marked "changed", I can't find a statement about what kind of review is needed for additions. I think RFC 2434 section 4 is pretty clear that this is needed. I propose the "specification required" level of review. Other thoughts? Randy From disman-admin@ietf.org Thu Oct 2 18:50:22 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 SAA29740 for ; Thu, 2 Oct 2003 18:50:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CGp-0007dt-38; Thu, 02 Oct 2003 18:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CGc-0007dP-E3 for disman@optimus.ietf.org; Thu, 02 Oct 2003 18:49:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29681 for ; Thu, 2 Oct 2003 18:49:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5CGZ-0007kU-00 for disman@ietf.org; Thu, 02 Oct 2003 18:49:47 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A5CGY-0007kR-00 for disman@ietf.org; Thu, 02 Oct 2003 18:49:46 -0400 Received: from h-68-164-29-208.snvacaid.dynamic.covad.net ([68.164.29.208] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5CGY-0003Jo-00 for disman@ietf.org; Thu, 02 Oct 2003 15:49:46 -0700 Message-ID: <003501c38937$7b3fef20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] ituAlarmActiveTrendIndication in draft-ietf-disman-alarm-mib-15.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, 2 Oct 2003 15:49:47 -0700 Hi - There's a superflous " " at the beginning of the text of the description clause for ituAlarmActiveTrendIndication. Ditto alarmActiveStatsGroup, alarmClearGroup, and ituAlarmTc. Randy From exim@www1.ietf.org Thu Oct 2 18:50: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 SAA29755 for ; Thu, 2 Oct 2003 18:50:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CGq-0007el-MA for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 18:50:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Mo46P029425 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 18:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CGq-0007eW-Fs for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 18:50:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29692 for ; Thu, 2 Oct 2003 18:49:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5CGn-0007ki-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 18:50:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5CGm-0007kf-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 18:50:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CGp-0007dt-38; Thu, 02 Oct 2003 18:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CGc-0007dP-E3 for disman@optimus.ietf.org; Thu, 02 Oct 2003 18:49:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29681 for ; Thu, 2 Oct 2003 18:49:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5CGZ-0007kU-00 for disman@ietf.org; Thu, 02 Oct 2003 18:49:47 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A5CGY-0007kR-00 for disman@ietf.org; Thu, 02 Oct 2003 18:49:46 -0400 Received: from h-68-164-29-208.snvacaid.dynamic.covad.net ([68.164.29.208] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5CGY-0003Jo-00 for disman@ietf.org; Thu, 02 Oct 2003 15:49:46 -0700 Message-ID: <003501c38937$7b3fef20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] ituAlarmActiveTrendIndication in draft-ietf-disman-alarm-mib-15.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, 2 Oct 2003 15:49:47 -0700 Hi - There's a superflous " " at the beginning of the text of the description clause for ituAlarmActiveTrendIndication. Ditto alarmActiveStatsGroup, alarmClearGroup, and ituAlarmTc. Randy From disman-admin@ietf.org Thu Oct 2 18:57: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 SAA29947 for ; Thu, 2 Oct 2003 18:57:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CNZ-0007l0-Ua; Thu, 02 Oct 2003 18:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CMx-0007k9-LV for disman@optimus.ietf.org; Thu, 02 Oct 2003 18:56:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29921 for ; Thu, 2 Oct 2003 18:56:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5CMu-0007nR-00 for disman@ietf.org; Thu, 02 Oct 2003 18:56:20 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A5CMt-0007nO-00 for disman@ietf.org; Thu, 02 Oct 2003 18:56:19 -0400 Received: from h-68-164-29-208.snvacaid.dynamic.covad.net ([68.164.29.208] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5CMt-00062D-00 for disman@ietf.org; Thu, 02 Oct 2003 15:56:19 -0700 Message-ID: <003a01c38938$658e3be0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] Security considerations in draft-ietf-disman-alarm-mib-15.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, 2 Oct 2003 15:56:20 -0700 Hi - WG chair hat on: > 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 ... > 75-2) This section should also mention throttling / DoS attacks based on > notification generation. > > Sharon->Neither of the examples given in the MIB Review Guidelines do ... Given the IESG's comments on the ARC MIB, I believe we need to reconsider this comment. Randy Presuhn, disman WG chair From exim@www1.ietf.org Thu Oct 2 18:57:22 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 SAA29962 for ; Thu, 2 Oct 2003 18:57:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CNb-0007ln-5G for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 18:57:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Mv3q3029861 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 18:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CNb-0007lY-16 for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 18:57:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29938 for ; Thu, 2 Oct 2003 18:56:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5CNX-0007nq-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 18:56:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5CNX-0007nn-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 18:56:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CNZ-0007l0-Ua; Thu, 02 Oct 2003 18:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CMx-0007k9-LV for disman@optimus.ietf.org; Thu, 02 Oct 2003 18:56:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29921 for ; Thu, 2 Oct 2003 18:56:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5CMu-0007nR-00 for disman@ietf.org; Thu, 02 Oct 2003 18:56:20 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A5CMt-0007nO-00 for disman@ietf.org; Thu, 02 Oct 2003 18:56:19 -0400 Received: from h-68-164-29-208.snvacaid.dynamic.covad.net ([68.164.29.208] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5CMt-00062D-00 for disman@ietf.org; Thu, 02 Oct 2003 15:56:19 -0700 Message-ID: <003a01c38938$658e3be0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] Security considerations in draft-ietf-disman-alarm-mib-15.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, 2 Oct 2003 15:56:20 -0700 Hi - WG chair hat on: > 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 ... > 75-2) This section should also mention throttling / DoS attacks based on > notification generation. > > Sharon->Neither of the examples given in the MIB Review Guidelines do ... Given the IESG's comments on the ARC MIB, I believe we need to reconsider this comment. Randy Presuhn, disman WG chair From disman-admin@ietf.org Thu Oct 2 19:07: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 TAA00152 for ; Thu, 2 Oct 2003 19:07:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CXE-0008K8-Kk; Thu, 02 Oct 2003 19:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CWb-0008JY-MU for disman@optimus.ietf.org; Thu, 02 Oct 2003 19:06:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00128 for ; Thu, 2 Oct 2003 19:06:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5CWY-00004u-00 for disman@ietf.org; Thu, 02 Oct 2003 19:06:18 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A5CWX-00004p-00 for disman@ietf.org; Thu, 02 Oct 2003 19:06:18 -0400 Received: from h-68-164-29-208.snvacaid.dynamic.covad.net ([68.164.29.208] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5CWX-0005xs-00 for disman@ietf.org; Thu, 02 Oct 2003 16:06:18 -0700 Message-ID: <003f01c38939$ca1327a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] ituAlarmServiceUserGroup etc. in draft-ietf-disman-alarm-mib-15.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, 2 Oct 2003 16:06:19 -0700 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 ... > 70) ituAlarmActiveDetector, ituAlarmActiveServiceProvider, and > ituAlarmActiveServiceUser need better DESCRIPTIONs. I think > it needs to be more explicit that their values are the names > of the object instances corresponding to these resources. > > 72) The DESCRIPTION of ituAlarmServiceUserGroup isn't helpful. > > Sharon->These are the descriptions used in the ITU. It would be a new > Sharon->design item to provide 'improved' descriptions. ... If the ITU definitions really are that vacuous, I guess we're stuck with them. The repeated "This group is optional" DESCRIPTIONs in ituAlarmCompliance don't make me feel any better, but if no one else is bothered by this, I'm willing to let it go and hope the IESG feels the same way. Randy, as disman WG chair. From exim@www1.ietf.org Thu Oct 2 19:07:22 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 TAA00167 for ; Thu, 2 Oct 2003 19:07:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CXH-0008Lr-A3 for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 19:07:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92N73ji032095 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 19:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CXG-0008LQ-HE for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 19:07:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00140 for ; Thu, 2 Oct 2003 19:06:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5CXD-00005C-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 19:06:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5CXC-000059-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 19:06:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CXE-0008K8-Kk; Thu, 02 Oct 2003 19:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CWb-0008JY-MU for disman@optimus.ietf.org; Thu, 02 Oct 2003 19:06:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00128 for ; Thu, 2 Oct 2003 19:06:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5CWY-00004u-00 for disman@ietf.org; Thu, 02 Oct 2003 19:06:18 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1A5CWX-00004p-00 for disman@ietf.org; Thu, 02 Oct 2003 19:06:18 -0400 Received: from h-68-164-29-208.snvacaid.dynamic.covad.net ([68.164.29.208] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5CWX-0005xs-00 for disman@ietf.org; Thu, 02 Oct 2003 16:06:18 -0700 Message-ID: <003f01c38939$ca1327a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] ituAlarmServiceUserGroup etc. in draft-ietf-disman-alarm-mib-15.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, 2 Oct 2003 16:06:19 -0700 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 ... > 70) ituAlarmActiveDetector, ituAlarmActiveServiceProvider, and > ituAlarmActiveServiceUser need better DESCRIPTIONs. I think > it needs to be more explicit that their values are the names > of the object instances corresponding to these resources. > > 72) The DESCRIPTION of ituAlarmServiceUserGroup isn't helpful. > > Sharon->These are the descriptions used in the ITU. It would be a new > Sharon->design item to provide 'improved' descriptions. ... If the ITU definitions really are that vacuous, I guess we're stuck with them. The repeated "This group is optional" DESCRIPTIONs in ituAlarmCompliance don't make me feel any better, but if no one else is bothered by this, I'm willing to let it go and hope the IESG feels the same way. Randy, as disman WG chair. From disman-admin@ietf.org Thu Oct 2 22:54: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 WAA05819 for ; Thu, 2 Oct 2003 22:54:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5G4v-0002WP-Ex; Thu, 02 Oct 2003 22:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5G4W-0002Vb-Ah for disman@optimus.ietf.org; Thu, 02 Oct 2003 22:53:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05787 for ; Thu, 2 Oct 2003 22:53:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5G4S-0002A4-00 for disman@ietf.org; Thu, 02 Oct 2003 22:53:32 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A5G4S-0002A0-00 for disman@ietf.org; Thu, 02 Oct 2003 22:53:32 -0400 Received: from h-68-165-71-168.snvacaid.dynamic.covad.net ([68.165.71.168] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5G4Q-0000Eg-00 for disman@ietf.org; Thu, 02 Oct 2003 19:53:30 -0700 Message-ID: <000b01c38959$877cbee0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] zero-based counters in draft-ietf-disman-alarm-mib-15.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, 2 Oct 2003 19:53:31 -0700 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 ... > 62) alarmActiveStatsActives, the SYNTAX says this is a Counter32, > but the DESCRIPTION sure makes it sound like it's supposed to > be zero-based. > > 71) ituAlarmActiveStatsIndeterminates, > ituAlarmActiveStatsCriticals, > ituAlarmActiveStatsMajors, > ituAlarmActiveStatsMinors, and > ituAlarmActiveStatsWarnings are all Counter32, but their > DESCRIPTIONs sound like they're assumed to be zero-based. > > Sharon-> Counter32 can have a value of 0. ... Let me put it another way: if none of these events have occured since system restart, what will the value of these objects be? a) zero, since the descriptions say they are counts "since system restart" if this is the case, they should use the ZeroBasedCounter32 TC b) not predictable, given the defnition of Counter32 in RFC 2578 clause 7.1.6 if this is the case, then the "since system restart" words are misleading Randy (technical contributor) From exim@www1.ietf.org Thu Oct 2 22:54:32 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 WAA05834 for ; Thu, 2 Oct 2003 22:54:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5G56-0002Xl-7U for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 22:54:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h932sCcw009776 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 22:54:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5G56-0002Xb-02 for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 22:54:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05800 for ; Thu, 2 Oct 2003 22:54:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5G52-0002AY-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 22:54:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5G51-0002AV-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 22:54:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5G4v-0002WP-Ex; Thu, 02 Oct 2003 22:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5G4W-0002Vb-Ah for disman@optimus.ietf.org; Thu, 02 Oct 2003 22:53:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05787 for ; Thu, 2 Oct 2003 22:53:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5G4S-0002A4-00 for disman@ietf.org; Thu, 02 Oct 2003 22:53:32 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A5G4S-0002A0-00 for disman@ietf.org; Thu, 02 Oct 2003 22:53:32 -0400 Received: from h-68-165-71-168.snvacaid.dynamic.covad.net ([68.165.71.168] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5G4Q-0000Eg-00 for disman@ietf.org; Thu, 02 Oct 2003 19:53:30 -0700 Message-ID: <000b01c38959$877cbee0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] zero-based counters in draft-ietf-disman-alarm-mib-15.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, 2 Oct 2003 19:53:31 -0700 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 ... > 62) alarmActiveStatsActives, the SYNTAX says this is a Counter32, > but the DESCRIPTION sure makes it sound like it's supposed to > be zero-based. > > 71) ituAlarmActiveStatsIndeterminates, > ituAlarmActiveStatsCriticals, > ituAlarmActiveStatsMajors, > ituAlarmActiveStatsMinors, and > ituAlarmActiveStatsWarnings are all Counter32, but their > DESCRIPTIONs sound like they're assumed to be zero-based. > > Sharon-> Counter32 can have a value of 0. ... Let me put it another way: if none of these events have occured since system restart, what will the value of these objects be? a) zero, since the descriptions say they are counts "since system restart" if this is the case, they should use the ZeroBasedCounter32 TC b) not predictable, given the defnition of Counter32 in RFC 2578 clause 7.1.6 if this is the case, then the "since system restart" words are misleading Randy (technical contributor) From disman-admin@ietf.org Thu Oct 2 23:18: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 XAA06418 for ; Thu, 2 Oct 2003 23:18:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5GS9-0003mc-SV; Thu, 02 Oct 2003 23:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5GRf-0003jA-PC for disman@optimus.ietf.org; Thu, 02 Oct 2003 23:17:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06386 for ; Thu, 2 Oct 2003 23:17:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5GRd-0002Np-00 for disman@ietf.org; Thu, 02 Oct 2003 23:17:29 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A5GRd-0002Nm-00 for disman@ietf.org; Thu, 02 Oct 2003 23:17:29 -0400 Received: from h-68-165-71-168.snvacaid.dynamic.covad.net ([68.165.71.168] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5GRe-0004Dl-00 for disman@ietf.org; Thu, 02 Oct 2003 20:17:30 -0700 Message-ID: <001501c3895c$e1afd7a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] LocalSnmpEngineOrZeroLenStr in draft-ietf-disman-alarm-mib-15.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, 2 Oct 2003 20:17:31 -0700 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 ... > 44) page 15 (LocalSnmpEngineOrZeroLenStr): where the DESCRIPTION > talks about "instantiation" doesn't make sense. I think it's > referring to use of the TC in an OBJECT-TYPE definition, rather > than object instantiation. > > Sharon -> This seems more a wordsmith thing. ... The DESCRIPTION still doesn't make sense. It currently says: "An SNMP Engine ID or a zero-length string. The instantiation of this object will provide guidance on when this will be an SNMP Engine ID and when it will be a zero lengths string" This is a TC definition, so "instantiation of this object will provide guidance" makes no sense at all to me. In both cases where this TC is used, the conditions for a zero-length string value are the same: either the notification came from a protocol (SNMPv1 is not the only one! don't forget SNMPv2c) which doesn't use SNMP Engine ID, or all entries in the table currently have the same Engine ID. (I guess that means that when one arrives from some other engine, all these objects' values will change from zero-length string back to their "real" values. Am I the only person bothered by this?) Randy From exim@www1.ietf.org Thu Oct 2 23:18:28 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 XAA06433 for ; Thu, 2 Oct 2003 23:18:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5GSF-0003nY-23 for disman-archive@odin.ietf.org; Thu, 02 Oct 2003 23:18:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h933I6Vg014597 for disman-archive@odin.ietf.org; Thu, 2 Oct 2003 23:18:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5GSE-0003nM-CH for disman-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 23:18:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06391 for ; Thu, 2 Oct 2003 23:17:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5GSC-0002O2-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 23:18:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5GSB-0002Nz-00 for disman-web-archive@ietf.org; Thu, 02 Oct 2003 23:18:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5GS9-0003mc-SV; Thu, 02 Oct 2003 23:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5GRf-0003jA-PC for disman@optimus.ietf.org; Thu, 02 Oct 2003 23:17:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06386 for ; Thu, 2 Oct 2003 23:17:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5GRd-0002Np-00 for disman@ietf.org; Thu, 02 Oct 2003 23:17:29 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A5GRd-0002Nm-00 for disman@ietf.org; Thu, 02 Oct 2003 23:17:29 -0400 Received: from h-68-165-71-168.snvacaid.dynamic.covad.net ([68.165.71.168] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5GRe-0004Dl-00 for disman@ietf.org; Thu, 02 Oct 2003 20:17:30 -0700 Message-ID: <001501c3895c$e1afd7a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] LocalSnmpEngineOrZeroLenStr in draft-ietf-disman-alarm-mib-15.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, 2 Oct 2003 20:17:31 -0700 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 ... > 44) page 15 (LocalSnmpEngineOrZeroLenStr): where the DESCRIPTION > talks about "instantiation" doesn't make sense. I think it's > referring to use of the TC in an OBJECT-TYPE definition, rather > than object instantiation. > > Sharon -> This seems more a wordsmith thing. ... The DESCRIPTION still doesn't make sense. It currently says: "An SNMP Engine ID or a zero-length string. The instantiation of this object will provide guidance on when this will be an SNMP Engine ID and when it will be a zero lengths string" This is a TC definition, so "instantiation of this object will provide guidance" makes no sense at all to me. In both cases where this TC is used, the conditions for a zero-length string value are the same: either the notification came from a protocol (SNMPv1 is not the only one! don't forget SNMPv2c) which doesn't use SNMP Engine ID, or all entries in the table currently have the same Engine ID. (I guess that means that when one arrives from some other engine, all these objects' values will change from zero-length string back to their "real" values. Am I the only person bothered by this?) Randy From disman-admin@ietf.org Fri Oct 3 00:42:22 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 AAA09123 for ; Fri, 3 Oct 2003 00:42:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5HlQ-0007KH-TD; Fri, 03 Oct 2003 00:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5HlC-0007K3-Bm for disman@optimus.ietf.org; Fri, 03 Oct 2003 00:41:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09100 for ; Fri, 3 Oct 2003 00:41:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Hl9-0003JH-00 for disman@ietf.org; Fri, 03 Oct 2003 00:41:43 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A5Hl9-0003JE-00 for disman@ietf.org; Fri, 03 Oct 2003 00:41:43 -0400 Received: from h-68-165-71-168.snvacaid.dynamic.covad.net ([68.165.71.168] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5Hl9-0003To-00 for disman@ietf.org; Thu, 02 Oct 2003 21:41:43 -0700 Message-ID: <002901c38968$a5ca2b80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] unfixed typo in alarm-mib-15 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, 2 Oct 2003 21:41:44 -0700 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 ... > 11) Page 4: "transmissions of management" -> > "transmission of management" (I personally think that > defining "notification" in terms of transmission is a > mistake, but it's too late to re-hash that discussion.) ... The typo "transmissions" -> "transmission" still needs to be fixed. Randy From exim@www1.ietf.org Fri Oct 3 00:42:24 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 AAA09138 for ; Fri, 3 Oct 2003 00:42:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5HlT-0007L9-TR for disman-archive@odin.ietf.org; Fri, 03 Oct 2003 00:42:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h934g33A028209 for disman-archive@odin.ietf.org; Fri, 3 Oct 2003 00:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5HlT-0007Ku-OX for disman-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 00:42:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09108 for ; Fri, 3 Oct 2003 00:41:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5HlQ-0003JT-00 for disman-web-archive@ietf.org; Fri, 03 Oct 2003 00:42:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5HlQ-0003JQ-00 for disman-web-archive@ietf.org; Fri, 03 Oct 2003 00:42:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5HlQ-0007KH-TD; Fri, 03 Oct 2003 00:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5HlC-0007K3-Bm for disman@optimus.ietf.org; Fri, 03 Oct 2003 00:41:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09100 for ; Fri, 3 Oct 2003 00:41:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Hl9-0003JH-00 for disman@ietf.org; Fri, 03 Oct 2003 00:41:43 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A5Hl9-0003JE-00 for disman@ietf.org; Fri, 03 Oct 2003 00:41:43 -0400 Received: from h-68-165-71-168.snvacaid.dynamic.covad.net ([68.165.71.168] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5Hl9-0003To-00 for disman@ietf.org; Thu, 02 Oct 2003 21:41:43 -0700 Message-ID: <002901c38968$a5ca2b80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] unfixed typo in alarm-mib-15 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, 2 Oct 2003 21:41:44 -0700 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 ... > 11) Page 4: "transmissions of management" -> > "transmission of management" (I personally think that > defining "notification" in terms of transmission is a > mistake, but it's too late to re-hash that discussion.) ... The typo "transmissions" -> "transmission" still needs to be fixed. Randy From disman-admin@ietf.org Fri Oct 3 00:50:22 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 AAA09303 for ; Fri, 3 Oct 2003 00:50:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5HtC-0007db-Ix; Fri, 03 Oct 2003 00:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5HsS-0007d1-QD for disman@optimus.ietf.org; Fri, 03 Oct 2003 00:49:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09279 for ; Fri, 3 Oct 2003 00:49:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5HsP-0003Mt-00 for disman@ietf.org; Fri, 03 Oct 2003 00:49:13 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A5HsP-0003Mq-00 for disman@ietf.org; Fri, 03 Oct 2003 00:49:13 -0400 Received: from h-68-165-71-168.snvacaid.dynamic.covad.net ([68.165.71.168] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5HsQ-0004EO-00 for disman@ietf.org; Thu, 02 Oct 2003 21:49:14 -0700 Message-ID: <002e01c38969$b2d54ac0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] definition of Alarm Raise in Comments on draft-ietf-disman-alarm-mib-15.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, 2 Oct 2003 21:49:15 -0700 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 ... > 14) Page 4: "A notification SHOULD be sent on alarm raise." > Given the definition of notification, and the role of RFC > 3413, this sentence should be deleted. Whether a notification > should be sent depends on whether some manager is interested > in it and has configured the SNMP-NOTIFICATION-MIB and > SNMP-TARGET-MIB accordingly. > > Sharon -> This was explicitly discussed and wg consensus was that it was OK > to indicate a preference for sending notifications. ... Perhaps I'm just getting denser, but I still don't see how this belongs in the definition for "Alarm Raise". The current text says: Alarm Raise The initial detection of the fault indicated by an alarm or any number of alarm states later entered, except clear. A Notification SHOULD be sent on alarm raise. The second sentence simply does not belong in the definition. Furthermore, the SHOULD language directly contradicts the normal functioning of this MIB module, which provides a means of controlling whether a Notification is issued, and the operation of RFC 3413, which controls whether it is sent anywhere. Randy (technical contributor) From exim@www1.ietf.org Fri Oct 3 00:50: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 AAA09318 for ; Fri, 3 Oct 2003 00:50:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5HtD-0007fD-O2 for disman-archive@odin.ietf.org; Fri, 03 Oct 2003 00:50:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h934o3tu029453 for disman-archive@odin.ietf.org; Fri, 3 Oct 2003 00:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5HtD-0007ey-Jq for disman-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 00:50:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09296 for ; Fri, 3 Oct 2003 00:49:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5HtA-0003NP-00 for disman-web-archive@ietf.org; Fri, 03 Oct 2003 00:50:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5HtA-0003NM-00 for disman-web-archive@ietf.org; Fri, 03 Oct 2003 00:50:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5HtC-0007db-Ix; Fri, 03 Oct 2003 00:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5HsS-0007d1-QD for disman@optimus.ietf.org; Fri, 03 Oct 2003 00:49:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09279 for ; Fri, 3 Oct 2003 00:49:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5HsP-0003Mt-00 for disman@ietf.org; Fri, 03 Oct 2003 00:49:13 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A5HsP-0003Mq-00 for disman@ietf.org; Fri, 03 Oct 2003 00:49:13 -0400 Received: from h-68-165-71-168.snvacaid.dynamic.covad.net ([68.165.71.168] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5HsQ-0004EO-00 for disman@ietf.org; Thu, 02 Oct 2003 21:49:14 -0700 Message-ID: <002e01c38969$b2d54ac0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] definition of Alarm Raise in Comments on draft-ietf-disman-alarm-mib-15.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, 2 Oct 2003 21:49:15 -0700 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 ... > 14) Page 4: "A notification SHOULD be sent on alarm raise." > Given the definition of notification, and the role of RFC > 3413, this sentence should be deleted. Whether a notification > should be sent depends on whether some manager is interested > in it and has configured the SNMP-NOTIFICATION-MIB and > SNMP-TARGET-MIB accordingly. > > Sharon -> This was explicitly discussed and wg consensus was that it was OK > to indicate a preference for sending notifications. ... Perhaps I'm just getting denser, but I still don't see how this belongs in the definition for "Alarm Raise". The current text says: Alarm Raise The initial detection of the fault indicated by an alarm or any number of alarm states later entered, except clear. A Notification SHOULD be sent on alarm raise. The second sentence simply does not belong in the definition. Furthermore, the SHOULD language directly contradicts the normal functioning of this MIB module, which provides a means of controlling whether a Notification is issued, and the operation of RFC 3413, which controls whether it is sent anywhere. Randy (technical contributor) From disman-admin@ietf.org Fri Oct 3 01:01: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 BAA09603 for ; Fri, 3 Oct 2003 01:01:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5I3r-0007xy-2U; Fri, 03 Oct 2003 01:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5I2w-0007wf-7v for disman@optimus.ietf.org; Fri, 03 Oct 2003 01:00:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09549 for ; Fri, 3 Oct 2003 00:59:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5I2t-0003Tl-00 for disman@ietf.org; Fri, 03 Oct 2003 01:00:03 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A5I2s-0003Ti-00 for disman@ietf.org; Fri, 03 Oct 2003 01:00:02 -0400 Received: from h-68-165-71-168.snvacaid.dynamic.covad.net ([68.165.71.168] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5I2t-0000W9-00 for disman@ietf.org; Thu, 02 Oct 2003 22:00:03 -0700 Message-ID: <003901c3896b$35801bc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] Technical changes to alarm MIB notification types 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, 2 Oct 2003 22:00:04 -0700 Hi - WG chair hat on... > 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 ... > 63) alarmActiveState, alarmClearState: the names for these notifications > aren't terribly good. more importantly, something needs to be said > about throttling per draft-ietf-ops-mib-review-guidelines-01.txt > section 4.7 last paragraph, perhaps simply to the effect that these > are "second order" notifications that rely on lower-level throttling > and filter specification. > > Sharon->I did this more in line with the examples in the review guidelines. ... There are some pretty significant changes to the definitions of these two notification types appearing with the -15-draft. I'd like to get a sense of the working group that this particular approach to notification throttling is appropriate for this MIB module. I'd like to hear from those who think this type of throttling is appropriate in this case, as well as from those who would prefer something else. As technical contributor: I still think "alarmActiveState" and "alarmClearState" are lousy names for notifications, and would prefer to *not* do throttling at this layer, but rather higher or lower in the processing stream. Randy From exim@www1.ietf.org Fri Oct 3 01:01: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 BAA09621 for ; Fri, 3 Oct 2003 01:01:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5I3s-0007yt-Uo for disman-archive@odin.ietf.org; Fri, 03 Oct 2003 01:01:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93514aC030677 for disman-archive@odin.ietf.org; Fri, 3 Oct 2003 01:01:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5I3s-0007yi-Rb for disman-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 01:01:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09588 for ; Fri, 3 Oct 2003 01:00:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5I3p-0003UQ-00 for disman-web-archive@ietf.org; Fri, 03 Oct 2003 01:01:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5I3p-0003UN-00 for disman-web-archive@ietf.org; Fri, 03 Oct 2003 01:01:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5I3r-0007xy-2U; Fri, 03 Oct 2003 01:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5I2w-0007wf-7v for disman@optimus.ietf.org; Fri, 03 Oct 2003 01:00:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09549 for ; Fri, 3 Oct 2003 00:59:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5I2t-0003Tl-00 for disman@ietf.org; Fri, 03 Oct 2003 01:00:03 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A5I2s-0003Ti-00 for disman@ietf.org; Fri, 03 Oct 2003 01:00:02 -0400 Received: from h-68-165-71-168.snvacaid.dynamic.covad.net ([68.165.71.168] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5I2t-0000W9-00 for disman@ietf.org; Thu, 02 Oct 2003 22:00:03 -0700 Message-ID: <003901c3896b$35801bc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] Technical changes to alarm MIB notification types 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, 2 Oct 2003 22:00:04 -0700 Hi - WG chair hat on... > 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 ... > 63) alarmActiveState, alarmClearState: the names for these notifications > aren't terribly good. more importantly, something needs to be said > about throttling per draft-ietf-ops-mib-review-guidelines-01.txt > section 4.7 last paragraph, perhaps simply to the effect that these > are "second order" notifications that rely on lower-level throttling > and filter specification. > > Sharon->I did this more in line with the examples in the review guidelines. ... There are some pretty significant changes to the definitions of these two notification types appearing with the -15-draft. I'd like to get a sense of the working group that this particular approach to notification throttling is appropriate for this MIB module. I'd like to hear from those who think this type of throttling is appropriate in this case, as well as from those who would prefer something else. As technical contributor: I still think "alarmActiveState" and "alarmClearState" are lousy names for notifications, and would prefer to *not* do throttling at this layer, but rather higher or lower in the processing stream. Randy From disman-admin@ietf.org Fri Oct 3 01:18:24 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 BAA09927 for ; Fri, 3 Oct 2003 01:18:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IKH-0000NI-7e; Fri, 03 Oct 2003 01:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IJP-0000KG-Cf for disman@optimus.ietf.org; Fri, 03 Oct 2003 01:17:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09879 for ; Fri, 3 Oct 2003 01:16:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5IJM-0003aP-00 for disman@ietf.org; Fri, 03 Oct 2003 01:17:04 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A5IJL-0003aM-00 for disman@ietf.org; Fri, 03 Oct 2003 01:17:03 -0400 Received: from h-68-165-71-168.snvacaid.dynamic.covad.net ([68.165.71.168] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5IJM-0003Dg-00 for disman@ietf.org; Thu, 02 Oct 2003 22:17:04 -0700 Message-ID: <004201c3896d$963370a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] varbind offsets in alarm-mib-15 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, 2 Oct 2003 22:17:05 -0700 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 ... > 47) (alarmModelVarbindIndex) (also alarmActiveVariableEntry) > I repeat my comments from May, since they're still not reflected in the > draft: > > > The words that are there now seem to be backwards from what I thought > > was agreed: since RFC 3416 is Standard, and 1157 is Historic, that the > > numbering should start with 1 for the SysUptime, which would be the > > value extracted from elsewhere in the PDU in the case of a SNMPv1 > > trap. What's there now (still) seems unnecessarily confusing. > > > > Note that Harrie Hazewinkel's message of March 18, 2003 also has > > concerns with this same paragraph. > > > > The discussion back in April 22, 2002 went the same way, and Sharon's > > post of June 3, 2002 gave the resolution of issue #38 as being to > > treat everything "v2-style". > > Sharon-> See Section 3.6 of the document ... The text now reads: 3.6 Notification Varbind Storage and Reference In SNMPv1 [RFC1157], the varbinds in the Trap-PDU sent over the wire map one to one into those varbinds listed in the SMI of the trap in the MIB in which it was defined[RFC1215]. In the case of linkDown trap, the first varbind can unambiguously be identified as ifIndex. With the introduction of the InformRequest-PDU and SNMPv2-Trap-PDU types, which send sysUptime and snmpTrapOID as the first two varbinds, while the SMI in the MIB where the Notification is defined only lists additional varbinds, the meaning of "first varbind" becomes less clear. In the case of the linkDown Notification, referring to the first varbind could potentially be interpreted as either the sysUptime or ifIndex. The varbind storage approach taken in the Alarm MIB is that sysUptime and snmpTrapOID SHALL always be stored in the active alarm variable table as entry 1 and 2 respectively, regardless of whether the transport was the Trap-PDU, the InformRequest-PDU or the SNMPv2-Trap-PDU. If the incoming Notification is 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]. So far, so good. But then the next paragraph says: 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. This seems unnecessarily convoluted, and results in an even more complicated alarmModelVarbindIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The index into the varbind listing of the notification indicated by alarmModelNotificationId which helps signal that the given alarm has changed state. If there is no applicable varbind, the value of this object MUST be zero. 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." DEFVAL { 0 } ::= { alarmModelEntry 4 } As a technical contributor, I think it's really twisted to warp everything into an SNMPv1 point of view. 1 should refer to the first varbind in alarmActiveVariableTable for a particular alarm. This is also needed for internal consistency with the DESCRIPTION of alarmActiveVariableEntry, which states: If the incoming notification is instead an SNMPv1 Trap-PDU and the value of alarmModelVarbindIndex is 1 or 2, an appropriate value for sysUpTime.0 or snmpTrapOID.0 shall be determined by using the rules in section 3.1 of [RFC3584]." As WG chair, I thought we had a clear consensus to do it the SNMPv3 way. Randy From exim@www1.ietf.org Fri Oct 3 01:18: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 BAA09942 for ; Fri, 3 Oct 2003 01:18:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IKJ-0000O5-Vo for disman-archive@odin.ietf.org; Fri, 03 Oct 2003 01:18:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h935I3Kd001483 for disman-archive@odin.ietf.org; Fri, 3 Oct 2003 01:18:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IKJ-0000Nq-PU for disman-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 01:18:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09902 for ; Fri, 3 Oct 2003 01:17:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5IKG-0003ax-00 for disman-web-archive@ietf.org; Fri, 03 Oct 2003 01:18:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5IKF-0003au-00 for disman-web-archive@ietf.org; Fri, 03 Oct 2003 01:17:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IKH-0000NI-7e; Fri, 03 Oct 2003 01:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IJP-0000KG-Cf for disman@optimus.ietf.org; Fri, 03 Oct 2003 01:17:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09879 for ; Fri, 3 Oct 2003 01:16:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5IJM-0003aP-00 for disman@ietf.org; Fri, 03 Oct 2003 01:17:04 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A5IJL-0003aM-00 for disman@ietf.org; Fri, 03 Oct 2003 01:17:03 -0400 Received: from h-68-165-71-168.snvacaid.dynamic.covad.net ([68.165.71.168] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5IJM-0003Dg-00 for disman@ietf.org; Thu, 02 Oct 2003 22:17:04 -0700 Message-ID: <004201c3896d$963370a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] varbind offsets in alarm-mib-15 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, 2 Oct 2003 22:17:05 -0700 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 ... > 47) (alarmModelVarbindIndex) (also alarmActiveVariableEntry) > I repeat my comments from May, since they're still not reflected in the > draft: > > > The words that are there now seem to be backwards from what I thought > > was agreed: since RFC 3416 is Standard, and 1157 is Historic, that the > > numbering should start with 1 for the SysUptime, which would be the > > value extracted from elsewhere in the PDU in the case of a SNMPv1 > > trap. What's there now (still) seems unnecessarily confusing. > > > > Note that Harrie Hazewinkel's message of March 18, 2003 also has > > concerns with this same paragraph. > > > > The discussion back in April 22, 2002 went the same way, and Sharon's > > post of June 3, 2002 gave the resolution of issue #38 as being to > > treat everything "v2-style". > > Sharon-> See Section 3.6 of the document ... The text now reads: 3.6 Notification Varbind Storage and Reference In SNMPv1 [RFC1157], the varbinds in the Trap-PDU sent over the wire map one to one into those varbinds listed in the SMI of the trap in the MIB in which it was defined[RFC1215]. In the case of linkDown trap, the first varbind can unambiguously be identified as ifIndex. With the introduction of the InformRequest-PDU and SNMPv2-Trap-PDU types, which send sysUptime and snmpTrapOID as the first two varbinds, while the SMI in the MIB where the Notification is defined only lists additional varbinds, the meaning of "first varbind" becomes less clear. In the case of the linkDown Notification, referring to the first varbind could potentially be interpreted as either the sysUptime or ifIndex. The varbind storage approach taken in the Alarm MIB is that sysUptime and snmpTrapOID SHALL always be stored in the active alarm variable table as entry 1 and 2 respectively, regardless of whether the transport was the Trap-PDU, the InformRequest-PDU or the SNMPv2-Trap-PDU. If the incoming Notification is 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]. So far, so good. But then the next paragraph says: 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. This seems unnecessarily convoluted, and results in an even more complicated alarmModelVarbindIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The index into the varbind listing of the notification indicated by alarmModelNotificationId which helps signal that the given alarm has changed state. If there is no applicable varbind, the value of this object MUST be zero. 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." DEFVAL { 0 } ::= { alarmModelEntry 4 } As a technical contributor, I think it's really twisted to warp everything into an SNMPv1 point of view. 1 should refer to the first varbind in alarmActiveVariableTable for a particular alarm. This is also needed for internal consistency with the DESCRIPTION of alarmActiveVariableEntry, which states: If the incoming notification is instead an SNMPv1 Trap-PDU and the value of alarmModelVarbindIndex is 1 or 2, an appropriate value for sysUpTime.0 or snmpTrapOID.0 shall be determined by using the rules in section 3.1 of [RFC3584]." As WG chair, I thought we had a clear consensus to do it the SNMPv3 way. Randy From disman-admin@ietf.org Fri Oct 3 01:32: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 BAA10219 for ; Fri, 3 Oct 2003 01:32:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IXp-0000sM-Az; Fri, 03 Oct 2003 01:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IX4-0000nz-7x for disman@optimus.ietf.org; Fri, 03 Oct 2003 01:31:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10205 for ; Fri, 3 Oct 2003 01:31:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5IX1-0003hF-00 for disman@ietf.org; Fri, 03 Oct 2003 01:31:11 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A5IX0-0003hC-00 for disman@ietf.org; Fri, 03 Oct 2003 01:31:10 -0400 Received: from h-68-165-71-168.snvacaid.dynamic.covad.net ([68.165.71.168] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5IX1-0002Pn-00 for disman@ietf.org; Thu, 02 Oct 2003 22:31:11 -0700 Message-ID: <004b01c3896f$8f48e480$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] "table wrapping" in alarm MIB -15- 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, 2 Oct 2003 22:31:12 -0700 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 ... ... > 75-4) I missed anything like an "alarmActiveMaximum", yet the document > doesn't seem to describe what should happen if there are too many active > alarms, as might happen if there are lots of instances of a particular type > of resource, and an administrator inadvertently specifies a frequent, > innocuous event as being of interest. > > Sharon->The design was normal table wrapping ... What is "normal table wrapping"? This is a new one for me. The document still needs to specify what happens. For example, if the alarm raise is lost, will the clear also be siletly suppressed? Even with frequency throttling in place, if alarms are sufficiently long lived there may still accumulate a very large number of them. Randy From exim@www1.ietf.org Fri Oct 3 01:32: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 BAA10234 for ; Fri, 3 Oct 2003 01:32:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IXq-0000tA-V8 for disman-archive@odin.ietf.org; Fri, 03 Oct 2003 01:32:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h935W2pP003410 for disman-archive@odin.ietf.org; Fri, 3 Oct 2003 01:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IXq-0000sv-Qf for disman-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 01:32:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10213 for ; Fri, 3 Oct 2003 01:31:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5IXn-0003hY-00 for disman-web-archive@ietf.org; Fri, 03 Oct 2003 01:31:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5IXn-0003hV-00 for disman-web-archive@ietf.org; Fri, 03 Oct 2003 01:31:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IXp-0000sM-Az; Fri, 03 Oct 2003 01:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IX4-0000nz-7x for disman@optimus.ietf.org; Fri, 03 Oct 2003 01:31:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10205 for ; Fri, 3 Oct 2003 01:31:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5IX1-0003hF-00 for disman@ietf.org; Fri, 03 Oct 2003 01:31:11 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A5IX0-0003hC-00 for disman@ietf.org; Fri, 03 Oct 2003 01:31:10 -0400 Received: from h-68-165-71-168.snvacaid.dynamic.covad.net ([68.165.71.168] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5IX1-0002Pn-00 for disman@ietf.org; Thu, 02 Oct 2003 22:31:11 -0700 Message-ID: <004b01c3896f$8f48e480$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] "table wrapping" in alarm MIB -15- 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, 2 Oct 2003 22:31:12 -0700 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 ... ... > 75-4) I missed anything like an "alarmActiveMaximum", yet the document > doesn't seem to describe what should happen if there are too many active > alarms, as might happen if there are lots of instances of a particular type > of resource, and an administrator inadvertently specifies a frequent, > innocuous event as being of interest. > > Sharon->The design was normal table wrapping ... What is "normal table wrapping"? This is a new one for me. The document still needs to specify what happens. For example, if the alarm raise is lost, will the clear also be siletly suppressed? Even with frequency throttling in place, if alarms are sufficiently long lived there may still accumulate a very large number of them. Randy From disman-admin@ietf.org Fri Oct 3 01:50: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 BAA10652 for ; Fri, 3 Oct 2003 01:50:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IpG-0001jK-3l; Fri, 03 Oct 2003 01:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Iow-0001iv-A2 for disman@optimus.ietf.org; Fri, 03 Oct 2003 01:49:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10598 for ; Fri, 3 Oct 2003 01:49:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Ios-0003oc-00 for disman@ietf.org; Fri, 03 Oct 2003 01:49:38 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A5Ios-0003oZ-00 for disman@ietf.org; Fri, 03 Oct 2003 01:49:38 -0400 Received: from h-68-165-71-168.snvacaid.dynamic.covad.net ([68.165.71.168] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5Iot-0005GG-00 for disman@ietf.org; Thu, 02 Oct 2003 22:49:39 -0700 Message-ID: <005201c38972$239d6320$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.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, 2 Oct 2003 22:49:40 -0700 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 Fri Oct 3 01:50: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 BAA10667 for ; Fri, 3 Oct 2003 01:50:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IpJ-0001k3-Hm for disman-archive@odin.ietf.org; Fri, 03 Oct 2003 01:50:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h935o5hP006692 for disman-archive@odin.ietf.org; Fri, 3 Oct 2003 01:50:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IpI-0001jr-Vv for disman-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 01:50:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10613 for ; Fri, 3 Oct 2003 01:49:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5IpF-0003p2-00 for disman-web-archive@ietf.org; Fri, 03 Oct 2003 01:50:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5IpF-0003oz-00 for disman-web-archive@ietf.org; Fri, 03 Oct 2003 01:50:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5IpG-0001jK-3l; Fri, 03 Oct 2003 01:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Iow-0001iv-A2 for disman@optimus.ietf.org; Fri, 03 Oct 2003 01:49:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10598 for ; Fri, 3 Oct 2003 01:49:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Ios-0003oc-00 for disman@ietf.org; Fri, 03 Oct 2003 01:49:38 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A5Ios-0003oZ-00 for disman@ietf.org; Fri, 03 Oct 2003 01:49:38 -0400 Received: from h-68-165-71-168.snvacaid.dynamic.covad.net ([68.165.71.168] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5Iot-0005GG-00 for disman@ietf.org; Thu, 02 Oct 2003 22:49:39 -0700 Message-ID: <005201c38972$239d6320$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.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, 2 Oct 2003 22:49:40 -0700 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 Fri Oct 3 15:47: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 PAA23613 for ; Fri, 3 Oct 2003 15:47:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VtF-0008LT-6U; Fri, 03 Oct 2003 15:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VtA-0008KT-1x for disman@optimus.ietf.org; Fri, 03 Oct 2003 15:46:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23569 for ; Fri, 3 Oct 2003 15:46:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Vt8-0005Vf-00 for disman@ietf.org; Fri, 03 Oct 2003 15:46:54 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1A5Vt8-0005VN-00 for disman@ietf.org; Fri, 03 Oct 2003 15:46:54 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h93JkGL05584; Fri, 3 Oct 2003 15:46:17 -0400 (EDT) Received: from zrtpd0jh.us.nortel.com ([47.140.202.34]) by zrtpd0j7.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZYG7QPP; Fri, 3 Oct 2003 15:46:16 -0400 Received: by zrtpd0jh.us.nortel.com with Internet Mail Service (5.5.2653.19) id <41VAZBQ3>; Fri, 3 Oct 2003 15:46:16 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408C9EB2A@zcard0ka.ca.nortel.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] (not) supporting multiple extensions via alarmModelS pecificPointer 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: Fri, 3 Oct 2003 15:46:12 -0400 Hi Without further object then, I will consider Randy-33 closed Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 01, 2003 6:57 PM To: Disman (E-mail) Subject: [Disman] (not) supporting multiple extensions via alarmModelSpecificPointer 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 ... > 33) Section 4.1.1: one consequence of this approach is that > one cannot use multiple extensions for a single alarm. > So, for example, one couldn't make an extension to the > ITU Alarm MIB and have it work using the method described here. > This may be the intent, but it would be good to be explicit about > it. ... The -15- text for section 4.1.1 still doesn't really acknowledge the inherent limitation of alarmModelSpecificPointer. Its syntax limits it to referring to a single extension. If one were to define another MIB containing a table augmenting the ITU alarm stuff, the value of alarmModelSpecificPointer would still presumably point to the ITU alarm stuff rather than the augmentation, so a management station would be left to grope around for this (and any other second- level) extensions. I'm *not* proposing that we change the design. I was (and still am) concerned as a technical contributor that we be upfront about the (perhaps theoretical) design limitation. If no one else cares about this, as WG chair I'm willing to let it go as is. but as a technical contributor I wanted to be sure that folks understood why I'm not 100% happy with the revised text here. Randy Randy From exim@www1.ietf.org Fri Oct 3 15:47: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 PAA23632 for ; Fri, 3 Oct 2003 15:47:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VtJ-0008MX-Kt for disman-archive@odin.ietf.org; Fri, 03 Oct 2003 15:47:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93Jl5oL032139 for disman-archive@odin.ietf.org; Fri, 3 Oct 2003 15:47:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VtJ-0008MI-HW for disman-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 15:47:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23579 for ; Fri, 3 Oct 2003 15:46:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5VtH-0005Vv-00 for disman-web-archive@ietf.org; Fri, 03 Oct 2003 15:47:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5VtH-0005Vr-00 for disman-web-archive@ietf.org; Fri, 03 Oct 2003 15:47:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VtF-0008LT-6U; Fri, 03 Oct 2003 15:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VtA-0008KT-1x for disman@optimus.ietf.org; Fri, 03 Oct 2003 15:46:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23569 for ; Fri, 3 Oct 2003 15:46:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Vt8-0005Vf-00 for disman@ietf.org; Fri, 03 Oct 2003 15:46:54 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1A5Vt8-0005VN-00 for disman@ietf.org; Fri, 03 Oct 2003 15:46:54 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h93JkGL05584; Fri, 3 Oct 2003 15:46:17 -0400 (EDT) Received: from zrtpd0jh.us.nortel.com ([47.140.202.34]) by zrtpd0j7.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZYG7QPP; Fri, 3 Oct 2003 15:46:16 -0400 Received: by zrtpd0jh.us.nortel.com with Internet Mail Service (5.5.2653.19) id <41VAZBQ3>; Fri, 3 Oct 2003 15:46:16 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408C9EB2A@zcard0ka.ca.nortel.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] (not) supporting multiple extensions via alarmModelS pecificPointer 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: Fri, 3 Oct 2003 15:46:12 -0400 Hi Without further object then, I will consider Randy-33 closed Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 01, 2003 6:57 PM To: Disman (E-mail) Subject: [Disman] (not) supporting multiple extensions via alarmModelSpecificPointer 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 ... > 33) Section 4.1.1: one consequence of this approach is that > one cannot use multiple extensions for a single alarm. > So, for example, one couldn't make an extension to the > ITU Alarm MIB and have it work using the method described here. > This may be the intent, but it would be good to be explicit about > it. ... The -15- text for section 4.1.1 still doesn't really acknowledge the inherent limitation of alarmModelSpecificPointer. Its syntax limits it to referring to a single extension. If one were to define another MIB containing a table augmenting the ITU alarm stuff, the value of alarmModelSpecificPointer would still presumably point to the ITU alarm stuff rather than the augmentation, so a management station would be left to grope around for this (and any other second- level) extensions. I'm *not* proposing that we change the design. I was (and still am) concerned as a technical contributor that we be upfront about the (perhaps theoretical) design limitation. If no one else cares about this, as WG chair I'm willing to let it go as is. but as a technical contributor I wanted to be sure that folks understood why I'm not 100% happy with the revised text here. Randy Randy From disman-admin@ietf.org Fri Oct 3 16:12:28 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 QAA24745 for ; Fri, 3 Oct 2003 16:12:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WHR-0000wV-Ae; Fri, 03 Oct 2003 16:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WGx-0000w8-43 for disman@optimus.ietf.org; Fri, 03 Oct 2003 16:11:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24673 for ; Fri, 3 Oct 2003 16:11:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5WGv-0005jL-00 for disman@ietf.org; Fri, 03 Oct 2003 16:11:29 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1A5WGu-0005iY-00 for disman@ietf.org; Fri, 03 Oct 2003 16:11:28 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h93KAvL20284; Fri, 3 Oct 2003 16:10:57 -0400 (EDT) Received: from zrtpd0jh.us.nortel.com ([47.140.202.34]) by zrtpd0j7.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZYG7VKM; Fri, 3 Oct 2003 16:10:57 -0400 Received: by zrtpd0jh.us.nortel.com with Internet Mail Service (5.5.2653.19) id <41VAZDWZ>; Fri, 3 Oct 2003 16:10:57 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408C9EB78@zcard0ka.ca.nortel.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: "Romascanu, Dan (Dan)" , Randy Presuhn Subject: RE: [Disman] alarmModelRowStatus 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: Fri, 3 Oct 2003 16:10:55 -0400 Hi We have a proposed resolution to Randy-49 - since all objects in the table have default values, no further changes are required. Objections? Sharon -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Thursday, October 02, 2003 3:51 AM To: Randy Presuhn; Disman (E-mail) Subject: RE: [Disman] alarmModelRowStatus > > 49) alarmModelRowStatus should spell out that the > > alarmModelVarbindIndex and alarmModelVarbindValue > > MUST be set before row can go active. > > > > Sharon-> I've fixed this another way. > ... > > AlarmModelRowStatus *still* needs to spell out what objects > are necessary > for the row to be activated. See > http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review- > guidelines-02.txt > > > - The DESCRIPTION clause of the status column MUST specify which > columnar objects (if any) have to be set to valid values before > the row can be activated. If any objects in cascading tables > have to be populated with related data before the row can be > activated, then this MUST also be specified. > > > Randy > Actually all read-create objects have a DEFVAL clause. If one would create a row without setting any of them, no harm would happen, other than a useless row being created. Do we need to say in this case that 'syntactically you can do it, bit it would be a loss of time'? Dan > > > From exim@www1.ietf.org Fri Oct 3 16:12: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 QAA24760 for ; Fri, 3 Oct 2003 16:12:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WHY-0000yN-5R for disman-archive@odin.ietf.org; Fri, 03 Oct 2003 16:12:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93KC82T003733 for disman-archive@odin.ietf.org; Fri, 3 Oct 2003 16:12:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WHX-0000y8-Vx for disman-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 16:12:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24712 for ; Fri, 3 Oct 2003 16:11:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5WHW-0005kb-00 for disman-web-archive@ietf.org; Fri, 03 Oct 2003 16:12:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5WHV-0005kY-00 for disman-web-archive@ietf.org; Fri, 03 Oct 2003 16:12:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WHR-0000wV-Ae; Fri, 03 Oct 2003 16:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WGx-0000w8-43 for disman@optimus.ietf.org; Fri, 03 Oct 2003 16:11:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24673 for ; Fri, 3 Oct 2003 16:11:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5WGv-0005jL-00 for disman@ietf.org; Fri, 03 Oct 2003 16:11:29 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1A5WGu-0005iY-00 for disman@ietf.org; Fri, 03 Oct 2003 16:11:28 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h93KAvL20284; Fri, 3 Oct 2003 16:10:57 -0400 (EDT) Received: from zrtpd0jh.us.nortel.com ([47.140.202.34]) by zrtpd0j7.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZYG7VKM; Fri, 3 Oct 2003 16:10:57 -0400 Received: by zrtpd0jh.us.nortel.com with Internet Mail Service (5.5.2653.19) id <41VAZDWZ>; Fri, 3 Oct 2003 16:10:57 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408C9EB78@zcard0ka.ca.nortel.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: "Romascanu, Dan (Dan)" , Randy Presuhn Subject: RE: [Disman] alarmModelRowStatus 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: Fri, 3 Oct 2003 16:10:55 -0400 Hi We have a proposed resolution to Randy-49 - since all objects in the table have default values, no further changes are required. Objections? Sharon -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Thursday, October 02, 2003 3:51 AM To: Randy Presuhn; Disman (E-mail) Subject: RE: [Disman] alarmModelRowStatus > > 49) alarmModelRowStatus should spell out that the > > alarmModelVarbindIndex and alarmModelVarbindValue > > MUST be set before row can go active. > > > > Sharon-> I've fixed this another way. > ... > > AlarmModelRowStatus *still* needs to spell out what objects > are necessary > for the row to be activated. See > http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review- > guidelines-02.txt > > > - The DESCRIPTION clause of the status column MUST specify which > columnar objects (if any) have to be set to valid values before > the row can be activated. If any objects in cascading tables > have to be populated with related data before the row can be > activated, then this MUST also be specified. > > > Randy > Actually all read-create objects have a DEFVAL clause. If one would create a row without setting any of them, no harm would happen, other than a useless row being created. Do we need to say in this case that 'syntactically you can do it, bit it would be a loss of time'? Dan > > > From disman-admin@ietf.org Fri Oct 3 22:41: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 WAA08490 for ; Fri, 3 Oct 2003 22:41:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5cLu-0000hb-Oy; Fri, 03 Oct 2003 22:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5cLD-0000ge-Vx for disman@optimus.ietf.org; Fri, 03 Oct 2003 22:40:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08443 for ; Fri, 3 Oct 2003 22:40:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5cLA-0002Gu-00 for disman@ietf.org; Fri, 03 Oct 2003 22:40:16 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1A5cL9-0002Gq-00 for disman@ietf.org; Fri, 03 Oct 2003 22:40:16 -0400 Received: from h-68-164-25-184.snvacaid.dynamic.covad.net ([68.164.25.184] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5cL9-0000nZ-00 for disman@ietf.org; Fri, 03 Oct 2003 19:40:15 -0700 Message-ID: <003201c38a20$d9d976c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408C9EB78@zcard0ka.ca.nortel.com> Subject: Re: [Disman] alarmModelRowStatus 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, 3 Oct 2003 19:40:19 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Romascanu, Dan (Dan)" ; "Randy Presuhn" > Sent: Friday, October 03, 2003 1:10 PM > Subject: RE: [Disman] alarmModelRowStatus ... > We have a proposed resolution to Randy-49 - since all objects in the table > have default values, no further changes are required. > > Objections? ... Yes. As MIB reviewer, I must point out yet again that the MIB review guidelines require us to specify "which columnar objects (if any) have to be set." Dan's comments (or something to similar effect) need to be reflected in the DESCRIPTION. Randy From exim@www1.ietf.org Fri Oct 3 22:41:28 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 WAA08505 for ; Fri, 3 Oct 2003 22:41:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5cM0-0000iU-7F for disman-archive@odin.ietf.org; Fri, 03 Oct 2003 22:41:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h942f85A002748 for disman-archive@odin.ietf.org; Fri, 3 Oct 2003 22:41:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5cM0-0000iF-0j for disman-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 22:41:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08474 for ; Fri, 3 Oct 2003 22:40:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5cLw-0002HN-00 for disman-web-archive@ietf.org; Fri, 03 Oct 2003 22:41:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5cLw-0002HJ-00 for disman-web-archive@ietf.org; Fri, 03 Oct 2003 22:41:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5cLu-0000hb-Oy; Fri, 03 Oct 2003 22:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5cLD-0000ge-Vx for disman@optimus.ietf.org; Fri, 03 Oct 2003 22:40:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08443 for ; Fri, 3 Oct 2003 22:40:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5cLA-0002Gu-00 for disman@ietf.org; Fri, 03 Oct 2003 22:40:16 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1A5cL9-0002Gq-00 for disman@ietf.org; Fri, 03 Oct 2003 22:40:16 -0400 Received: from h-68-164-25-184.snvacaid.dynamic.covad.net ([68.164.25.184] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A5cL9-0000nZ-00 for disman@ietf.org; Fri, 03 Oct 2003 19:40:15 -0700 Message-ID: <003201c38a20$d9d976c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408C9EB78@zcard0ka.ca.nortel.com> Subject: Re: [Disman] alarmModelRowStatus 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, 3 Oct 2003 19:40:19 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Romascanu, Dan (Dan)" ; "Randy Presuhn" > Sent: Friday, October 03, 2003 1:10 PM > Subject: RE: [Disman] alarmModelRowStatus ... > We have a proposed resolution to Randy-49 - since all objects in the table > have default values, no further changes are required. > > Objections? ... Yes. As MIB reviewer, I must point out yet again that the MIB review guidelines require us to specify "which columnar objects (if any) have to be set." Dan's comments (or something to similar effect) need to be reflected in the DESCRIPTION. Randy From disman-admin@ietf.org Mon Oct 6 16:54:29 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 QAA21781 for ; Mon, 6 Oct 2003 16:54:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6cMi-0000Vo-LX; Mon, 06 Oct 2003 16:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6cME-0000VD-Js for disman@optimus.ietf.org; Mon, 06 Oct 2003 16:53:30 -0400 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21770 for ; Mon, 6 Oct 2003 16:53:20 -0400 (EDT) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1A6cK2-0005oA-FU; Mon, 06 Oct 2003 16:51:14 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Subject: [Disman] Protocol Action: 'Alarm Reporting Control MIB' to Proposed Standard 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, 06 Oct 2003 16:51:14 -0400 The IESG has approved following document: - 'Alarm Reporting Control MIB ' as a Proposed Standard This document is the product of the Distributed Management Working Group. The IESG contact persons are Bert Wijnen and Randy Bush. Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for controlling the reporting of alarm conditions. Working Group Summary The Working Group reached consensus to request publication of this document as a Proposed Standard. Input from ITU-T and DMTF has been considered during development of this document and the concerns raised have been accommodated. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen RFC-Editor Notes: 1.In Section 4 "ARC MIB Overview", add the following text as a new paragraph after the 5th paragraph (The 5th paragraph is the one starts with the sentence: This document defines ....) Defined in M.3100 Amendment 3 [M.3100 Amd3], there are five ARC states: alm, nalm, nalmQI, nalmQICD and nalmTI. In the ARC MIB module, the arcState object is defined to model the M.3100 ARC states. Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., into the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. 2.On page 6, replace DESCRIPTION clause of arcTable with: DESCRIPTION "A table of Alarm Reporting Control (ARC) settings on the system. Alarm Reporting Control is a feature that provides an automatic in-service provisioning capability. Alarm reporting is turned off on a per-resource basis for a selective set of potential alarm conditions to allow sufficient time for customer testing and other maintenance activities in an 'alarm free' state. Once a resource is ready for service, alarm reporting is automatically or manually turned on. Functional description and requirements of Alarm Reporting Control are defined in ITU-T Recommendation M.3100 Amendment 3 [M.3100 Amd3]." 3.On page 9, replace DESCRIPTION clause of arcState with: DESCRIPTION "Defined in M.3100 Amendment 3 [M.3100 Amd3], there are five ARC states: alm, nalm, nalmQI, nalmQICD, and nalmTI. alm: Alarm reporting is turned on (i.e., is allowed). nalm: Alarm reporting is turned off (i.e., not allowed). nalmQI: nalm - Qualified Inhibit. Alarm reporting is turned off until the managed entity is qualified problem-free for an optional persistence interval. Problem-free means that the condition corresponding to the specified alarm type is cleared. nalmQICD: nalmQI - Count down. This is a substate of nalmQI and performs the persistence timing countdown function after the managed entity is qualified problem-free. nalmTI: nalm - Timed Inhibit. Alarm reporting is turned off for a specified time interval. alm may transition to nalm, nalmQI or nalmTI by management request. nalm may transition to alm, nalmQI or nalmTI by management request. nalmQI may transition to nalm or alm by management request. nalmQI may transition to alm automatically if qualified problem-free (if nalmQICD is not supported) or if the CD timer expired (if nalmQICD is supported) nalmTI may transition to alm or nalm by management request. nalmTI may transition to alm automatically if the TI timer expired. Further details of ARC state transitions are defined in Figure 3 of M.3100 Amd3 [M.3100 Amd3]. According to the requirements in M.3100 Amd3, a resource supporting the ARC feature shall support the alm state and at least one of the nalm, nalmTI, and nalmQI states. The nalmQICD state is an optional substate of nalmQI. The arcState object controls the alarm reporting state of a resource. Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., in the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. The nalamQICD state is a transitional state from nalmQI to alm. It is optional depending on the resource type and the implementation of the the resource. If it is supported, before the state transitions from nalmQI to alm, a count down period is activated for a duration set by the object arcNalmCDTimeInterval. When the time is up, the arcState transitions to alm." 4.In security section, page 13, replace this 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 netowrk. with this 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. 5.Please add page numbers to Table of Contents -30- From exim@www1.ietf.org Mon Oct 6 17:01:14 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 RAA22237 for ; Mon, 6 Oct 2003 17:01:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6cTO-0000nZ-5B for disman-archive@odin.ietf.org; Mon, 06 Oct 2003 17:00:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96L0sg6003068 for disman-archive@odin.ietf.org; Mon, 6 Oct 2003 17:00:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6cTN-0000nP-Ry for disman-web-archive@optimus.ietf.org; Mon, 06 Oct 2003 17:00:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22131 for ; Mon, 6 Oct 2003 17:00:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6cTL-0003mY-00 for disman-web-archive@ietf.org; Mon, 06 Oct 2003 17:00:51 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6cMp-0003dT-00 for disman-web-archive@ietf.org; Mon, 06 Oct 2003 16:54:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6cMi-0000Vo-LX; Mon, 06 Oct 2003 16:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6cME-0000VD-Js for disman@optimus.ietf.org; Mon, 06 Oct 2003 16:53:30 -0400 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21770 for ; Mon, 6 Oct 2003 16:53:20 -0400 (EDT) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1A6cK2-0005oA-FU; Mon, 06 Oct 2003 16:51:14 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Subject: [Disman] Protocol Action: 'Alarm Reporting Control MIB' to Proposed Standard 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, 06 Oct 2003 16:51:14 -0400 The IESG has approved following document: - 'Alarm Reporting Control MIB ' as a Proposed Standard This document is the product of the Distributed Management Working Group. The IESG contact persons are Bert Wijnen and Randy Bush. Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for controlling the reporting of alarm conditions. Working Group Summary The Working Group reached consensus to request publication of this document as a Proposed Standard. Input from ITU-T and DMTF has been considered during development of this document and the concerns raised have been accommodated. Protocol Quality This document has been reviewed for the IESG by Bert Wijnen RFC-Editor Notes: 1.In Section 4 "ARC MIB Overview", add the following text as a new paragraph after the 5th paragraph (The 5th paragraph is the one starts with the sentence: This document defines ....) Defined in M.3100 Amendment 3 [M.3100 Amd3], there are five ARC states: alm, nalm, nalmQI, nalmQICD and nalmTI. In the ARC MIB module, the arcState object is defined to model the M.3100 ARC states. Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., into the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. 2.On page 6, replace DESCRIPTION clause of arcTable with: DESCRIPTION "A table of Alarm Reporting Control (ARC) settings on the system. Alarm Reporting Control is a feature that provides an automatic in-service provisioning capability. Alarm reporting is turned off on a per-resource basis for a selective set of potential alarm conditions to allow sufficient time for customer testing and other maintenance activities in an 'alarm free' state. Once a resource is ready for service, alarm reporting is automatically or manually turned on. Functional description and requirements of Alarm Reporting Control are defined in ITU-T Recommendation M.3100 Amendment 3 [M.3100 Amd3]." 3.On page 9, replace DESCRIPTION clause of arcState with: DESCRIPTION "Defined in M.3100 Amendment 3 [M.3100 Amd3], there are five ARC states: alm, nalm, nalmQI, nalmQICD, and nalmTI. alm: Alarm reporting is turned on (i.e., is allowed). nalm: Alarm reporting is turned off (i.e., not allowed). nalmQI: nalm - Qualified Inhibit. Alarm reporting is turned off until the managed entity is qualified problem-free for an optional persistence interval. Problem-free means that the condition corresponding to the specified alarm type is cleared. nalmQICD: nalmQI - Count down. This is a substate of nalmQI and performs the persistence timing countdown function after the managed entity is qualified problem-free. nalmTI: nalm - Timed Inhibit. Alarm reporting is turned off for a specified time interval. alm may transition to nalm, nalmQI or nalmTI by management request. nalm may transition to alm, nalmQI or nalmTI by management request. nalmQI may transition to nalm or alm by management request. nalmQI may transition to alm automatically if qualified problem-free (if nalmQICD is not supported) or if the CD timer expired (if nalmQICD is supported) nalmTI may transition to alm or nalm by management request. nalmTI may transition to alm automatically if the TI timer expired. Further details of ARC state transitions are defined in Figure 3 of M.3100 Amd3 [M.3100 Amd3]. According to the requirements in M.3100 Amd3, a resource supporting the ARC feature shall support the alm state and at least one of the nalm, nalmTI, and nalmQI states. The nalmQICD state is an optional substate of nalmQI. The arcState object controls the alarm reporting state of a resource. Note that the state alm (alarm reporting is allowed) is not listed in the enumeration of the value of this object. However, this state is implicitly supported by the mib. Once a resource enters the normal reporting mode (i.e., in the alm state) for the specified alarm type, the corresponding row will be automatically deleted from the arc table. Also the manual setting of arcState to alm can be achieved through setting the RowStatus object to 'destroy'. The nalamQICD state is a transitional state from nalmQI to alm. It is optional depending on the resource type and the implementation of the the resource. If it is supported, before the state transitions from nalmQI to alm, a count down period is activated for a duration set by the object arcNalmCDTimeInterval. When the time is up, the arcState transitions to alm." 4.In security section, page 13, replace this 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 netowrk. with this 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. 5.Please add page numbers to Table of Contents -30- From disman-admin@ietf.org Tue Oct 7 12:42: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 MAA11119 for ; Tue, 7 Oct 2003 12:42:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6uuO-0002it-Kx; Tue, 07 Oct 2003 12:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6utn-0002f2-OD for disman@optimus.ietf.org; Tue, 07 Oct 2003 12:41:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11065 for ; Tue, 7 Oct 2003 12:41:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6utl-0000cB-00 for disman@ietf.org; Tue, 07 Oct 2003 12:41:21 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A6utl-0000bg-00 for disman@ietf.org; Tue, 07 Oct 2003 12:41:21 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h97GejW01515 for ; Tue, 7 Oct 2003 12:40:45 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 12:40:45 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D27D50@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Disman] Closed item from Randy's Review Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 7 Oct 2003 12:40:44 -0400 Hi 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 Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From exim@www1.ietf.org Tue Oct 7 12:42: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 MAA11134 for ; Tue, 7 Oct 2003 12:42:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6uuU-0002ji-6k for disman-archive@odin.ietf.org; Tue, 07 Oct 2003 12:42:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97Gg6hZ010512 for disman-archive@odin.ietf.org; Tue, 7 Oct 2003 12:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6uuU-0002jT-2L for disman-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 12:42:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11082 for ; Tue, 7 Oct 2003 12:41:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6uuS-0000cX-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 12:42:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6uuR-0000cU-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 12:42:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6uuO-0002it-Kx; Tue, 07 Oct 2003 12:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6utn-0002f2-OD for disman@optimus.ietf.org; Tue, 07 Oct 2003 12:41:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11065 for ; Tue, 7 Oct 2003 12:41:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6utl-0000cB-00 for disman@ietf.org; Tue, 07 Oct 2003 12:41:21 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A6utl-0000bg-00 for disman@ietf.org; Tue, 07 Oct 2003 12:41:21 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h97GejW01515 for ; Tue, 7 Oct 2003 12:40:45 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 12:40:45 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D27D50@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Disman] Closed item from Randy's Review Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 7 Oct 2003 12:40:44 -0400 Hi 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 Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From disman-admin@ietf.org Tue Oct 7 13:00:24 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 NAA11631 for ; Tue, 7 Oct 2003 13:00:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vBp-0003P4-Fl; Tue, 07 Oct 2003 13:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vAx-0003O0-NL for disman@optimus.ietf.org; Tue, 07 Oct 2003 12:59:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11596 for ; Tue, 7 Oct 2003 12:58:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6vAv-0000og-00 for disman@ietf.org; Tue, 07 Oct 2003 12:59:05 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A6vAv-0000oM-00 for disman@ietf.org; Tue, 07 Oct 2003 12:59:05 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h97GwXg02054 for ; Tue, 7 Oct 2003 12:58:34 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 12:58:34 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D27D98@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] section 4.1.3 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, 7 Oct 2003 12:58:33 -0400 Hi I think the updated text is actually a bit more confusing than the original, which is probably a sign that we have reached the wordsmithing stage. How's this: "in an architecture as described in section 3.2. Regardless of what is defined in the SNMP-TARGET-MIB, specifying no Notifications in the alarmModelNotificationId would result in no Notifications being logged or sent to management stations as a consequence of this particular alarm state transition." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 01, 2003 7:23 PM To: Disman (E-mail) Subject: [Disman] section 4.1.3 in 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 ... > 35) Section 4.1.3: (see comment 14 above) this paragraph doesn't > tell the whole story of what a manager needs to do to get > these notifications. The sentence beginning with "alternatively" > only makes things worse, since it will result in a configuration > that is contrary to the goal in the paragraph's topic sentence. ... The updated text is better. However, the last sentence in the first paragraph is misleading: in an architecture as described in section 3.2. Specifying no Notifications in the alarmModelNotificationId, regardless of what is defined in the SNMP-TARGET-MIB, would result in no Notifications being logged or sent to management stations. Suggested replacement: in an architecture as described in section 3.2. Specifying no Notifications in the alarmModelNotificationId, regardless of what is defined in the SNMP-TARGET-MIB, would result in no Notifications being logged or sent to management stations as a consequence of this particular alarm state transition. Randy From exim@www1.ietf.org Tue Oct 7 13:00: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 NAA11646 for ; Tue, 7 Oct 2003 13:00:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vBu-0003QM-3y for disman-archive@odin.ietf.org; Tue, 07 Oct 2003 13:00:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97H06L0013147 for disman-archive@odin.ietf.org; Tue, 7 Oct 2003 13:00:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vBt-0003Ps-7R for disman-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 13:00:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11607 for ; Tue, 7 Oct 2003 12:59:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6vBr-0000oy-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 13:00:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6vBq-0000ov-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 13:00:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vBp-0003P4-Fl; Tue, 07 Oct 2003 13:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vAx-0003O0-NL for disman@optimus.ietf.org; Tue, 07 Oct 2003 12:59:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11596 for ; Tue, 7 Oct 2003 12:58:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6vAv-0000og-00 for disman@ietf.org; Tue, 07 Oct 2003 12:59:05 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A6vAv-0000oM-00 for disman@ietf.org; Tue, 07 Oct 2003 12:59:05 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h97GwXg02054 for ; Tue, 7 Oct 2003 12:58:34 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 12:58:34 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D27D98@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] section 4.1.3 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, 7 Oct 2003 12:58:33 -0400 Hi I think the updated text is actually a bit more confusing than the original, which is probably a sign that we have reached the wordsmithing stage. How's this: "in an architecture as described in section 3.2. Regardless of what is defined in the SNMP-TARGET-MIB, specifying no Notifications in the alarmModelNotificationId would result in no Notifications being logged or sent to management stations as a consequence of this particular alarm state transition." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 01, 2003 7:23 PM To: Disman (E-mail) Subject: [Disman] section 4.1.3 in 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 ... > 35) Section 4.1.3: (see comment 14 above) this paragraph doesn't > tell the whole story of what a manager needs to do to get > these notifications. The sentence beginning with "alternatively" > only makes things worse, since it will result in a configuration > that is contrary to the goal in the paragraph's topic sentence. ... The updated text is better. However, the last sentence in the first paragraph is misleading: in an architecture as described in section 3.2. Specifying no Notifications in the alarmModelNotificationId, regardless of what is defined in the SNMP-TARGET-MIB, would result in no Notifications being logged or sent to management stations. Suggested replacement: in an architecture as described in section 3.2. Specifying no Notifications in the alarmModelNotificationId, regardless of what is defined in the SNMP-TARGET-MIB, would result in no Notifications being logged or sent to management stations as a consequence of this particular alarm state transition. Randy From disman-admin@ietf.org Tue Oct 7 13:32: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 NAA12790 for ; Tue, 7 Oct 2003 13:32:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vgm-0004xX-E9; Tue, 07 Oct 2003 13:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vgD-0004rh-Hf for disman@optimus.ietf.org; Tue, 07 Oct 2003 13:31:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12762 for ; Tue, 7 Oct 2003 13:31:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6vgB-00017d-00 for disman@ietf.org; Tue, 07 Oct 2003 13:31:23 -0400 Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by ietf-mx with esmtp (Exim 4.12) id 1A6vgA-00017a-00 for disman@ietf.org; Tue, 07 Oct 2003 13:31:23 -0400 Received: from h-68-165-65-192.snvacaid.dynamic.covad.net ([68.165.65.192] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A6vgA-00060V-00 for disman@ietf.org; Tue, 07 Oct 2003 10:31:22 -0700 Message-ID: <00fe01c38cf8$da9e6ea0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D27D50@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Closed item from Randy's Review 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: Tue, 7 Oct 2003 10:31:34 -0700 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 Tue Oct 7 13:32:24 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 NAA12809 for ; Tue, 7 Oct 2003 13:32:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vgo-0004yJ-LE for disman-archive@odin.ietf.org; Tue, 07 Oct 2003 13:32:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97HW2Oa019105 for disman-archive@odin.ietf.org; Tue, 7 Oct 2003 13:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vgo-0004y4-H3 for disman-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 13:32:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12776 for ; Tue, 7 Oct 2003 13:31:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6vgm-00017y-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 13:32:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6vgm-00017v-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 13:32:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vgm-0004xX-E9; Tue, 07 Oct 2003 13:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vgD-0004rh-Hf for disman@optimus.ietf.org; Tue, 07 Oct 2003 13:31:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12762 for ; Tue, 7 Oct 2003 13:31:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6vgB-00017d-00 for disman@ietf.org; Tue, 07 Oct 2003 13:31:23 -0400 Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by ietf-mx with esmtp (Exim 4.12) id 1A6vgA-00017a-00 for disman@ietf.org; Tue, 07 Oct 2003 13:31:23 -0400 Received: from h-68-165-65-192.snvacaid.dynamic.covad.net ([68.165.65.192] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A6vgA-00060V-00 for disman@ietf.org; Tue, 07 Oct 2003 10:31:22 -0700 Message-ID: <00fe01c38cf8$da9e6ea0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D27D50@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Closed item from Randy's Review 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: Tue, 7 Oct 2003 10:31:34 -0700 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 Tue Oct 7 13:36:22 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 NAA12945 for ; Tue, 7 Oct 2003 13:36:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vke-00054V-OO; Tue, 07 Oct 2003 13:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vkW-00054C-Eg for disman@optimus.ietf.org; Tue, 07 Oct 2003 13:35:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12930 for ; Tue, 7 Oct 2003 13:35:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6vkU-0001AQ-00 for disman@ietf.org; Tue, 07 Oct 2003 13:35:50 -0400 Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by ietf-mx with esmtp (Exim 4.12) id 1A6vkT-0001AN-00 for disman@ietf.org; Tue, 07 Oct 2003 13:35:49 -0400 Received: from h-68-165-65-192.snvacaid.dynamic.covad.net ([68.165.65.192] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A6vkT-0005sG-00 for disman@ietf.org; Tue, 07 Oct 2003 10:35:49 -0700 Message-ID: <010701c38cf9$79f43a20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D27D98@zcard0ka.ca.nortel.com> Subject: Re: [Disman] section 4.1.3 in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 7 Oct 2003 10:36:01 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Tuesday, October 07, 2003 9:58 AM > Subject: RE: [Disman] section 4.1.3 in draft-ietf-disman-alarm-mib-15.txt ... > I think the updated text is actually a bit more confusing than the original, > which is probably a sign that we have reached the wordsmithing stage. How's > this: > > "in an architecture as described in section 3.2. Regardless of > what is defined in the SNMP-TARGET-MIB, specifying no > Notifications in the alarmModelNotificationId would result in > no Notifications being logged or sent to management stations as > a consequence of this particular alarm state transition." It's fine with me, but to address your concern, it might seem less confusing if the first "no Notifications" were "{ 0 0 }" and if the second "no Notifications" were "no notifications". Randy From exim@www1.ietf.org Tue Oct 7 13:36: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 NAA12960 for ; Tue, 7 Oct 2003 13:36:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vkg-00057J-2j for disman-archive@odin.ietf.org; Tue, 07 Oct 2003 13:36:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97Ha2Q6019669 for disman-archive@odin.ietf.org; Tue, 7 Oct 2003 13:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vkf-00057A-QE for disman-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 13:36:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12937 for ; Tue, 7 Oct 2003 13:35:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6vkd-0001Aa-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 13:35:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6vkd-0001AX-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 13:35:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vke-00054V-OO; Tue, 07 Oct 2003 13:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vkW-00054C-Eg for disman@optimus.ietf.org; Tue, 07 Oct 2003 13:35:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12930 for ; Tue, 7 Oct 2003 13:35:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6vkU-0001AQ-00 for disman@ietf.org; Tue, 07 Oct 2003 13:35:50 -0400 Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by ietf-mx with esmtp (Exim 4.12) id 1A6vkT-0001AN-00 for disman@ietf.org; Tue, 07 Oct 2003 13:35:49 -0400 Received: from h-68-165-65-192.snvacaid.dynamic.covad.net ([68.165.65.192] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A6vkT-0005sG-00 for disman@ietf.org; Tue, 07 Oct 2003 10:35:49 -0700 Message-ID: <010701c38cf9$79f43a20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D27D98@zcard0ka.ca.nortel.com> Subject: Re: [Disman] section 4.1.3 in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 7 Oct 2003 10:36:01 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Tuesday, October 07, 2003 9:58 AM > Subject: RE: [Disman] section 4.1.3 in draft-ietf-disman-alarm-mib-15.txt ... > I think the updated text is actually a bit more confusing than the original, > which is probably a sign that we have reached the wordsmithing stage. How's > this: > > "in an architecture as described in section 3.2. Regardless of > what is defined in the SNMP-TARGET-MIB, specifying no > Notifications in the alarmModelNotificationId would result in > no Notifications being logged or sent to management stations as > a consequence of this particular alarm state transition." It's fine with me, but to address your concern, it might seem less confusing if the first "no Notifications" were "{ 0 0 }" and if the second "no Notifications" were "no notifications". Randy From disman-admin@ietf.org Tue Oct 7 13:56:28 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 NAA13881 for ; Tue, 7 Oct 2003 13:56:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6w41-0006Cj-Go; Tue, 07 Oct 2003 13:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6w3p-0006AY-Kd for disman@optimus.ietf.org; Tue, 07 Oct 2003 13:55:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13800 for ; Tue, 7 Oct 2003 13:55:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6w3n-0001R5-00 for disman@ietf.org; Tue, 07 Oct 2003 13:55:47 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A6w3m-0001QM-00 for disman@ietf.org; Tue, 07 Oct 2003 13:55:46 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h97Ht9J00978 for ; Tue, 7 Oct 2003 13:55:10 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 13:45:50 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D27E47@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn 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: Tue, 7 Oct 2003 13:45:49 -0400 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 Tue Oct 7 13:56: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 NAA13896 for ; Tue, 7 Oct 2003 13:56:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6w48-0006G2-Ma for disman-archive@odin.ietf.org; Tue, 07 Oct 2003 13:56:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97Hu8Rc024048 for disman-archive@odin.ietf.org; Tue, 7 Oct 2003 13:56:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6w48-0006Fn-IV for disman-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 13:56:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13831 for ; Tue, 7 Oct 2003 13:55:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6w46-0001Ry-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 13:56:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6w45-0001Ru-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 13:56:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6w41-0006Cj-Go; Tue, 07 Oct 2003 13:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6w3p-0006AY-Kd for disman@optimus.ietf.org; Tue, 07 Oct 2003 13:55:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13800 for ; Tue, 7 Oct 2003 13:55:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6w3n-0001R5-00 for disman@ietf.org; Tue, 07 Oct 2003 13:55:47 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A6w3m-0001QM-00 for disman@ietf.org; Tue, 07 Oct 2003 13:55:46 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h97Ht9J00978 for ; Tue, 7 Oct 2003 13:55:10 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 13:45:50 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D27E47@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn 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: Tue, 7 Oct 2003 13:45:49 -0400 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 Tue Oct 7 13:57: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 NAA13953 for ; Tue, 7 Oct 2003 13:57:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6w4x-0006If-MC; Tue, 07 Oct 2003 13:56:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6w4W-0006Hi-9C for disman@optimus.ietf.org; Tue, 07 Oct 2003 13:56:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13846 for ; Tue, 7 Oct 2003 13:56:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6w4T-0001SO-00 for disman@ietf.org; Tue, 07 Oct 2003 13:56:29 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A6w4T-0001RV-00 for disman@ietf.org; Tue, 07 Oct 2003 13:56:29 -0400 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 h97HtuL00869 for ; Tue, 7 Oct 2003 13:55:57 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 13:55:57 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D27E7C@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] section 4.1.3 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, 7 Oct 2003 13:55:56 -0400 Hi The following is the proposed resolution to Randy-35. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 4.1.3, replace " in an architecture as described in section 3.2. Specifying no Notifications in the alarmModelNotificationId, regardless of what is defined in the SNMP-TARGET-MIB, would result in no Notifications being logged or sent to management stations." With "in an architecture as described in section 3.2. Regardless of what is defined in the SNMP-TARGET-MIB, specifying { 0 0 } in the alarmModelNotificationId would result in no notifications being logged or sent to management stations as a consequence of this particular alarm state transition." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 07, 2003 1:36 PM To: Disman (E-mail) Subject: Re: [Disman] section 4.1.3 in draft-ietf-disman-alarm-mib-15.txt Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Tuesday, October 07, 2003 9:58 AM > Subject: RE: [Disman] section 4.1.3 in > draft-ietf-disman-alarm-mib-15.txt ... > I think the updated text is actually a bit more confusing than the > original, which is probably a sign that we have reached the > wordsmithing stage. How's > this: > > "in an architecture as described in section 3.2. Regardless of > what is defined in the SNMP-TARGET-MIB, specifying no > Notifications in the alarmModelNotificationId would result in > no Notifications being logged or sent to management stations as > a consequence of this particular alarm state transition." It's fine with me, but to address your concern, it might seem less confusing if the first "no Notifications" were "{ 0 0 }" and if the second "no Notifications" were "no notifications". Randy From exim@www1.ietf.org Tue Oct 7 13:57:34 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 NAA13983 for ; Tue, 7 Oct 2003 13:57:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6w5B-0006LM-4z for disman-archive@odin.ietf.org; Tue, 07 Oct 2003 13:57:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97HvDea024378 for disman-archive@odin.ietf.org; Tue, 7 Oct 2003 13:57:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6w5A-0006L7-Vb for disman-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 13:57:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13932 for ; Tue, 7 Oct 2003 13:57:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6w4w-0001T5-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 13:56:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6w4w-0001T2-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 13:56:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6w4x-0006If-MC; Tue, 07 Oct 2003 13:56:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6w4W-0006Hi-9C for disman@optimus.ietf.org; Tue, 07 Oct 2003 13:56:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13846 for ; Tue, 7 Oct 2003 13:56:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6w4T-0001SO-00 for disman@ietf.org; Tue, 07 Oct 2003 13:56:29 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A6w4T-0001RV-00 for disman@ietf.org; Tue, 07 Oct 2003 13:56:29 -0400 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 h97HtuL00869 for ; Tue, 7 Oct 2003 13:55:57 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 13:55:57 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D27E7C@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] section 4.1.3 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, 7 Oct 2003 13:55:56 -0400 Hi The following is the proposed resolution to Randy-35. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 4.1.3, replace " in an architecture as described in section 3.2. Specifying no Notifications in the alarmModelNotificationId, regardless of what is defined in the SNMP-TARGET-MIB, would result in no Notifications being logged or sent to management stations." With "in an architecture as described in section 3.2. Regardless of what is defined in the SNMP-TARGET-MIB, specifying { 0 0 } in the alarmModelNotificationId would result in no notifications being logged or sent to management stations as a consequence of this particular alarm state transition." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 07, 2003 1:36 PM To: Disman (E-mail) Subject: Re: [Disman] section 4.1.3 in draft-ietf-disman-alarm-mib-15.txt Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Tuesday, October 07, 2003 9:58 AM > Subject: RE: [Disman] section 4.1.3 in > draft-ietf-disman-alarm-mib-15.txt ... > I think the updated text is actually a bit more confusing than the > original, which is probably a sign that we have reached the > wordsmithing stage. How's > this: > > "in an architecture as described in section 3.2. Regardless of > what is defined in the SNMP-TARGET-MIB, specifying no > Notifications in the alarmModelNotificationId would result in > no Notifications being logged or sent to management stations as > a consequence of this particular alarm state transition." It's fine with me, but to address your concern, it might seem less confusing if the first "no Notifications" were "{ 0 0 }" and if the second "no Notifications" were "no notifications". Randy From disman-admin@ietf.org Tue Oct 7 14:27: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 OAA15445 for ; Tue, 7 Oct 2003 14:27:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wY0-0007lS-G1; Tue, 07 Oct 2003 14:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wX3-0007kF-Hs for disman@optimus.ietf.org; Tue, 07 Oct 2003 14:26:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15412 for ; Tue, 7 Oct 2003 14:25:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6wX0-0001uR-00 for disman@ietf.org; Tue, 07 Oct 2003 14:25:58 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A6wX0-0001uA-00 for disman@ietf.org; Tue, 07 Oct 2003 14:25:58 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h97IPOe01184 for ; Tue, 7 Oct 2003 14:25:25 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 14:20:11 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D27EEF@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] Section 3.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, 7 Oct 2003 14:20:08 -0400 Hi The following is the proposed resolution to Randy-12. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 3.1, replace " in the International Telecommunications Union (ITU) model - cleared, indeterminate, critical, major, minor and warning." With " in the International Telecommunications Union (ITU) model [M.3100] - cleared, indeterminate, critical, major, minor and warning." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 01, 2003 6:33 PM To: Disman (E-mail) Subject: [Disman] Section 3.1 in 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 ... > 12) Page 4: "ITU" acronym should be expanded, for > "ITU model" a reference should be given. ... Although this item was marked "Changed", I see there is still no reference for "ITU model". Is there a rationale for omitting the reference, or was it just an oversight? Randy From exim@www1.ietf.org Tue Oct 7 14:27: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 OAA15463 for ; Tue, 7 Oct 2003 14:27:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wY2-0007mC-Ej for disman-archive@odin.ietf.org; Tue, 07 Oct 2003 14:27:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97IR21T029892 for disman-archive@odin.ietf.org; Tue, 7 Oct 2003 14:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wY2-0007m2-Ar for disman-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 14:27:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15431 for ; Tue, 7 Oct 2003 14:26:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6wXz-0001uw-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 14:26:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6wXz-0001ut-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 14:26:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wY0-0007lS-G1; Tue, 07 Oct 2003 14:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wX3-0007kF-Hs for disman@optimus.ietf.org; Tue, 07 Oct 2003 14:26:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15412 for ; Tue, 7 Oct 2003 14:25:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6wX0-0001uR-00 for disman@ietf.org; Tue, 07 Oct 2003 14:25:58 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A6wX0-0001uA-00 for disman@ietf.org; Tue, 07 Oct 2003 14:25:58 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h97IPOe01184 for ; Tue, 7 Oct 2003 14:25:25 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 14:20:11 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D27EEF@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] Section 3.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, 7 Oct 2003 14:20:08 -0400 Hi The following is the proposed resolution to Randy-12. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 3.1, replace " in the International Telecommunications Union (ITU) model - cleared, indeterminate, critical, major, minor and warning." With " in the International Telecommunications Union (ITU) model [M.3100] - cleared, indeterminate, critical, major, minor and warning." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 01, 2003 6:33 PM To: Disman (E-mail) Subject: [Disman] Section 3.1 in 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 ... > 12) Page 4: "ITU" acronym should be expanded, for > "ITU model" a reference should be given. ... Although this item was marked "Changed", I see there is still no reference for "ITU model". Is there a rationale for omitting the reference, or was it just an oversight? Randy From disman-admin@ietf.org Tue Oct 7 14:41: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 OAA15887 for ; Tue, 7 Oct 2003 14:41:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wlX-00006H-SD; Tue, 07 Oct 2003 14:40:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wlB-00005u-HR for disman@optimus.ietf.org; Tue, 07 Oct 2003 14:40:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15861 for ; Tue, 7 Oct 2003 14:40:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6wl8-000219-00 for disman@ietf.org; Tue, 07 Oct 2003 14:40:34 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A6wl8-00020w-00 for disman@ietf.org; Tue, 07 Oct 2003 14:40:34 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h97IdrP00684 for ; Tue, 7 Oct 2003 14:39:55 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 14:32:56 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D27F22@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] Unexpanded acronym 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, 7 Oct 2003 14:32:53 -0400 Hi The following is the proposed resolution to Randy-17. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 4.1, which is the first occurrence of Object Identifier or OID, replace " assume as well as the Object Identifier of the Notification" With " assume as well as the Object Identifier (OID) of the Notification" Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 01, 2003 6:37 PM To: Disman (E-mail) Subject: [Disman] Unexpanded acronym 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 ... > 17) Page 6: "OID" acronym should be expanded ... Although this one is marked "Changed", the result is that the acronym now occurs for the first time on page 16, but still without expansion. Randy From exim@www1.ietf.org Tue Oct 7 14:41:22 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 OAA15902 for ; Tue, 7 Oct 2003 14:41:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wlZ-000073-Vf for disman-archive@odin.ietf.org; Tue, 07 Oct 2003 14:41:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97If1sr000427 for disman-archive@odin.ietf.org; Tue, 7 Oct 2003 14:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wlZ-00006o-Qo for disman-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 14:41:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15875 for ; Tue, 7 Oct 2003 14:40:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6wlX-00021O-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 14:40:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6wlW-00021L-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 14:40:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wlX-00006H-SD; Tue, 07 Oct 2003 14:40:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wlB-00005u-HR for disman@optimus.ietf.org; Tue, 07 Oct 2003 14:40:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15861 for ; Tue, 7 Oct 2003 14:40:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6wl8-000219-00 for disman@ietf.org; Tue, 07 Oct 2003 14:40:34 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A6wl8-00020w-00 for disman@ietf.org; Tue, 07 Oct 2003 14:40:34 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h97IdrP00684 for ; Tue, 7 Oct 2003 14:39:55 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 14:32:56 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D27F22@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] Unexpanded acronym 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, 7 Oct 2003 14:32:53 -0400 Hi The following is the proposed resolution to Randy-17. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 4.1, which is the first occurrence of Object Identifier or OID, replace " assume as well as the Object Identifier of the Notification" With " assume as well as the Object Identifier (OID) of the Notification" Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 01, 2003 6:37 PM To: Disman (E-mail) Subject: [Disman] Unexpanded acronym 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 ... > 17) Page 6: "OID" acronym should be expanded ... Although this one is marked "Changed", the result is that the acronym now occurs for the first time on page 16, but still without expansion. Randy From disman-admin@ietf.org Tue Oct 7 14:43:22 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 OAA15963 for ; Tue, 7 Oct 2003 14:43:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wnV-0000GW-92; Tue, 07 Oct 2003 14:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wn1-0000At-HB for disman@optimus.ietf.org; Tue, 07 Oct 2003 14:42:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15936 for ; Tue, 7 Oct 2003 14:42:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6wmy-00021t-00 for disman@ietf.org; Tue, 07 Oct 2003 14:42:28 -0400 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by ietf-mx with esmtp (Exim 4.12) id 1A6wmy-00021q-00 for disman@ietf.org; Tue, 07 Oct 2003 14:42:28 -0400 Received: from h-68-165-66-37.snvacaid.dynamic.covad.net ([68.165.66.37] helo=oemcomputer) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A6wmx-0000On-00 for disman@ietf.org; Tue, 07 Oct 2003 11:42:27 -0700 Message-ID: <000601c38d02$c8c4d660$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] section 3.3.3 in draft-ietf-disman-alarm-mib-15.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: Tue, 7 Oct 2003 11:42:36 -0700 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 ... > 24) Section 3.3.3: the first sentence is a bit hard to swallow: > as a practical matter, to find out which notifications are > not of interest, one would have to walk the alarm model table > to find out what *is* of interest, and then remove that set > from the set of all possible notifications, which isn't listed > in any convenient spot. ... Proposed fix: CURRENT: The Alarm MIB provides a means to tell what Notifications are just informational events or not of interest to the manager for other reasons by not including them in any alarm models. In addition, REPLACEMENT: The Alarm MIB provides a means to determine whether a given notification is not of interest to managers for purposes of alarm management by permitting inspection of the alarm models. If no entries in the alarmModelTable could match a particular notification, then that notification is not relevant to the alarm models defined. In addition, Randy From exim@www1.ietf.org Tue Oct 7 14:43: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 OAA15980 for ; Tue, 7 Oct 2003 14:43:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wnW-0000II-Le for disman-archive@odin.ietf.org; Tue, 07 Oct 2003 14:43:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97Ih2wo001124 for disman-archive@odin.ietf.org; Tue, 7 Oct 2003 14:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wnW-0000I3-H2 for disman-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 14:43:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15950 for ; Tue, 7 Oct 2003 14:42:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6wnT-00022D-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 14:42:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6wnT-000228-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 14:42:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wnV-0000GW-92; Tue, 07 Oct 2003 14:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wn1-0000At-HB for disman@optimus.ietf.org; Tue, 07 Oct 2003 14:42:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15936 for ; Tue, 7 Oct 2003 14:42:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6wmy-00021t-00 for disman@ietf.org; Tue, 07 Oct 2003 14:42:28 -0400 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by ietf-mx with esmtp (Exim 4.12) id 1A6wmy-00021q-00 for disman@ietf.org; Tue, 07 Oct 2003 14:42:28 -0400 Received: from h-68-165-66-37.snvacaid.dynamic.covad.net ([68.165.66.37] helo=oemcomputer) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A6wmx-0000On-00 for disman@ietf.org; Tue, 07 Oct 2003 11:42:27 -0700 Message-ID: <000601c38d02$c8c4d660$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] section 3.3.3 in draft-ietf-disman-alarm-mib-15.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: Tue, 7 Oct 2003 11:42:36 -0700 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 ... > 24) Section 3.3.3: the first sentence is a bit hard to swallow: > as a practical matter, to find out which notifications are > not of interest, one would have to walk the alarm model table > to find out what *is* of interest, and then remove that set > from the set of all possible notifications, which isn't listed > in any convenient spot. ... Proposed fix: CURRENT: The Alarm MIB provides a means to tell what Notifications are just informational events or not of interest to the manager for other reasons by not including them in any alarm models. In addition, REPLACEMENT: The Alarm MIB provides a means to determine whether a given notification is not of interest to managers for purposes of alarm management by permitting inspection of the alarm models. If no entries in the alarmModelTable could match a particular notification, then that notification is not relevant to the alarm models defined. In addition, Randy From disman-admin@ietf.org Tue Oct 7 14:44: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 OAA16056 for ; Tue, 7 Oct 2003 14:44:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6woS-0000Kk-SG; Tue, 07 Oct 2003 14:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wo1-0000Jt-5n for disman@optimus.ietf.org; Tue, 07 Oct 2003 14:43:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15979 for ; Tue, 7 Oct 2003 14:43:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6wny-00023H-00 for disman@ietf.org; Tue, 07 Oct 2003 14:43:30 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A6wnx-00022E-00 for disman@ietf.org; Tue, 07 Oct 2003 14:43:29 -0400 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 h97IgwL01016 for ; Tue, 7 Oct 2003 14:42:58 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 14:42:58 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D27F50@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] Section 4.1.7 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: Tue, 7 Oct 2003 14:42:56 -0400 Hi The following is the proposed resolution to Randy-42. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 4.1.7, replace " named alarm lists. A middle manager could, create an alarmListName" With " named alarm lists. A middle manager could create an alarmListName" Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 01, 2003 7:27 PM To: Disman (E-mail) Subject: [Disman] Section 4.1.7 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 ... > 42) 4.1.7: "therefore," -> "" ... There's a superfluous comma left over in this line on page 14: named alarm lists. A middle manager could, create an alarmListName Randy From exim@www1.ietf.org Tue Oct 7 14:44:22 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 OAA16071 for ; Tue, 7 Oct 2003 14:44:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6woU-0000Ne-43 for disman-archive@odin.ietf.org; Tue, 07 Oct 2003 14:44:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97Ii2M4001456 for disman-archive@odin.ietf.org; Tue, 7 Oct 2003 14:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6woT-0000NP-VC for disman-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 14:44:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16024 for ; Tue, 7 Oct 2003 14:43:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6woR-00024D-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 14:43:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6woQ-00024A-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 14:43:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6woS-0000Kk-SG; Tue, 07 Oct 2003 14:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wo1-0000Jt-5n for disman@optimus.ietf.org; Tue, 07 Oct 2003 14:43:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15979 for ; Tue, 7 Oct 2003 14:43:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6wny-00023H-00 for disman@ietf.org; Tue, 07 Oct 2003 14:43:30 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A6wnx-00022E-00 for disman@ietf.org; Tue, 07 Oct 2003 14:43:29 -0400 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 h97IgwL01016 for ; Tue, 7 Oct 2003 14:42:58 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 14:42:58 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D27F50@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] Section 4.1.7 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: Tue, 7 Oct 2003 14:42:56 -0400 Hi The following is the proposed resolution to Randy-42. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 4.1.7, replace " named alarm lists. A middle manager could, create an alarmListName" With " named alarm lists. A middle manager could create an alarmListName" Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 01, 2003 7:27 PM To: Disman (E-mail) Subject: [Disman] Section 4.1.7 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 ... > 42) 4.1.7: "therefore," -> "" ... There's a superfluous comma left over in this line on page 14: named alarm lists. A middle manager could, create an alarmListName Randy From disman-admin@ietf.org Tue Oct 7 14:49: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 OAA16249 for ; Tue, 7 Oct 2003 14:49:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wtI-0000XO-KC; Tue, 07 Oct 2003 14:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wsY-0000Wu-LL for disman@optimus.ietf.org; Tue, 07 Oct 2003 14:48:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16206 for ; Tue, 7 Oct 2003 14:48:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6wsV-00026g-00 for disman@ietf.org; Tue, 07 Oct 2003 14:48:11 -0400 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by ietf-mx with esmtp (Exim 4.12) id 1A6wsV-00026d-00 for disman@ietf.org; Tue, 07 Oct 2003 14:48:11 -0400 Received: from h-68-165-66-37.snvacaid.dynamic.covad.net ([68.165.66.37] helo=oemcomputer) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A6wsV-0002Lk-00 for disman@ietf.org; Tue, 07 Oct 2003 11:48:11 -0700 Message-ID: <000d01c38d03$95ad80a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] Section 4.1.5 in draft-ietf-disman-alarm-mib-15.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: Tue, 7 Oct 2003 11:48:22 -0700 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 ... > 39) 4.1.5: "table can, and probably should, be" -> > "table MAY be". I don't think we had consensus > to make this a SHOULD, but I'm open to the possibility. ... Proposed change: OLD: 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. NEW: The alarm model table MAY 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. (I have no problems with "SHOULD", but I think "can, and probably should" does not belong in standards-track material.) Randy From exim@www1.ietf.org Tue Oct 7 14:49:22 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 OAA16267 for ; Tue, 7 Oct 2003 14:49:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wtJ-0000Z0-Ns for disman-archive@odin.ietf.org; Tue, 07 Oct 2003 14:49:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97In16p002160 for disman-archive@odin.ietf.org; Tue, 7 Oct 2003 14:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wtJ-0000Yl-Ja for disman-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 14:49:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16240 for ; Tue, 7 Oct 2003 14:48:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6wtG-00026y-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 14:48:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6wtG-00026v-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 14:48:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wtI-0000XO-KC; Tue, 07 Oct 2003 14:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wsY-0000Wu-LL for disman@optimus.ietf.org; Tue, 07 Oct 2003 14:48:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16206 for ; Tue, 7 Oct 2003 14:48:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6wsV-00026g-00 for disman@ietf.org; Tue, 07 Oct 2003 14:48:11 -0400 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by ietf-mx with esmtp (Exim 4.12) id 1A6wsV-00026d-00 for disman@ietf.org; Tue, 07 Oct 2003 14:48:11 -0400 Received: from h-68-165-66-37.snvacaid.dynamic.covad.net ([68.165.66.37] helo=oemcomputer) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A6wsV-0002Lk-00 for disman@ietf.org; Tue, 07 Oct 2003 11:48:11 -0700 Message-ID: <000d01c38d03$95ad80a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] Section 4.1.5 in draft-ietf-disman-alarm-mib-15.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: Tue, 7 Oct 2003 11:48:22 -0700 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 ... > 39) 4.1.5: "table can, and probably should, be" -> > "table MAY be". I don't think we had consensus > to make this a SHOULD, but I'm open to the possibility. ... Proposed change: OLD: 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. NEW: The alarm model table MAY 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. (I have no problems with "SHOULD", but I think "can, and probably should" does not belong in standards-track material.) Randy From disman-admin@ietf.org Tue Oct 7 15:19: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 PAA18400 for ; Tue, 7 Oct 2003 15:19:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xMK-0001k3-PC; Tue, 07 Oct 2003 15:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xM8-0001jo-I4 for disman@optimus.ietf.org; Tue, 07 Oct 2003 15:18:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18360 for ; Tue, 7 Oct 2003 15:18:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6xM7-0002PY-00 for disman@ietf.org; Tue, 07 Oct 2003 15:18:47 -0400 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by ietf-mx with esmtp (Exim 4.12) id 1A6xM6-0002PV-00 for disman@ietf.org; Tue, 07 Oct 2003 15:18:46 -0400 Received: from h-68-165-66-37.snvacaid.dynamic.covad.net ([68.165.66.37] helo=oemcomputer) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A6xM5-0000XN-00 for disman@ietf.org; Tue, 07 Oct 2003 12:18:45 -0700 Message-ID: <001c01c38d07$dad6bee0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] alarm comment 69-1 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 7 Oct 2003 12:18:56 -0700 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 ... > 69-1) ituAlarmEntry: the DESCRIPTION needs to say something about how > rows in this table come into existence. Currently, it looks like > immaculate conception. If these things are created under management > control, then I'd strongly suggest DEFVALs for > ituAlarmPerceivedSeverity, > ituAlarmEventType, ituAlarmProbableCause, and ituAlarmAdditionalText. ... Let me step through my reasoning for wanting a clearer description of the lifecycle of these things. Perhaps someone can point out where I've gone wrong, or, if my reasoning is correct, how we might fix things. Currently, the table definition reads: ituAlarmTable OBJECT-TYPE SYNTAX SEQUENCE OF ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of ITU Alarm information for possible alarms on the system." ::= { ituAlarmModel 1 } 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 } The DESCRIPTIONs (and lack of RowStatus) would lead one to believe that these are static tables that describe the possible severity levels that can occur on a system. However, the INDEX structure ties these to the alarmModelTable. Entries in the alarmModelTable may be created (and deleted) using AlarmModelRowStatus, so the values of alarmListName and alarmModelIndex may be coming from a manager somewhere. This begs several questions: 1) when a new alarm model is created using RowStatus, do corresponding entries automagically appear in the ituAlarmTable? Do they appear as a side-effect of setting alarmModelSpecificPointer? If so, are the indexing constraints on possible legal values for this pointer enforced by the agent? 2) If corresponding entries automatically appear in the ituAlarmTable when new alarmModelTable entries are created, how are the values for the various columns supplied? 3) if an alarmModelEntry is deleted, what happens to the corresponding ituAlarmModelEntries (since it's a one-to-many relationship due to ituAlarmPerceivedSeverity, I assume they will always appear and disappear six at a time.) Does this help to explain why I'd like the DESCRIPTIONs to better explain what's going on with this table? Randy From exim@www1.ietf.org Tue Oct 7 15:19:28 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 PAA18415 for ; Tue, 7 Oct 2003 15:19:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xMQ-0001m5-FK for disman-archive@odin.ietf.org; Tue, 07 Oct 2003 15:19:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97JJ6Um006815 for disman-archive@odin.ietf.org; Tue, 7 Oct 2003 15:19:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xMQ-0001lq-9e for disman-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 15:19:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18383 for ; Tue, 7 Oct 2003 15:18:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6xMO-0002Pk-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 15:19:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6xMO-0002Ph-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 15:19:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xMK-0001k3-PC; Tue, 07 Oct 2003 15:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xM8-0001jo-I4 for disman@optimus.ietf.org; Tue, 07 Oct 2003 15:18:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18360 for ; Tue, 7 Oct 2003 15:18:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6xM7-0002PY-00 for disman@ietf.org; Tue, 07 Oct 2003 15:18:47 -0400 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by ietf-mx with esmtp (Exim 4.12) id 1A6xM6-0002PV-00 for disman@ietf.org; Tue, 07 Oct 2003 15:18:46 -0400 Received: from h-68-165-66-37.snvacaid.dynamic.covad.net ([68.165.66.37] helo=oemcomputer) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A6xM5-0000XN-00 for disman@ietf.org; Tue, 07 Oct 2003 12:18:45 -0700 Message-ID: <001c01c38d07$dad6bee0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] alarm comment 69-1 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 7 Oct 2003 12:18:56 -0700 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 ... > 69-1) ituAlarmEntry: the DESCRIPTION needs to say something about how > rows in this table come into existence. Currently, it looks like > immaculate conception. If these things are created under management > control, then I'd strongly suggest DEFVALs for > ituAlarmPerceivedSeverity, > ituAlarmEventType, ituAlarmProbableCause, and ituAlarmAdditionalText. ... Let me step through my reasoning for wanting a clearer description of the lifecycle of these things. Perhaps someone can point out where I've gone wrong, or, if my reasoning is correct, how we might fix things. Currently, the table definition reads: ituAlarmTable OBJECT-TYPE SYNTAX SEQUENCE OF ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of ITU Alarm information for possible alarms on the system." ::= { ituAlarmModel 1 } 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 } The DESCRIPTIONs (and lack of RowStatus) would lead one to believe that these are static tables that describe the possible severity levels that can occur on a system. However, the INDEX structure ties these to the alarmModelTable. Entries in the alarmModelTable may be created (and deleted) using AlarmModelRowStatus, so the values of alarmListName and alarmModelIndex may be coming from a manager somewhere. This begs several questions: 1) when a new alarm model is created using RowStatus, do corresponding entries automagically appear in the ituAlarmTable? Do they appear as a side-effect of setting alarmModelSpecificPointer? If so, are the indexing constraints on possible legal values for this pointer enforced by the agent? 2) If corresponding entries automatically appear in the ituAlarmTable when new alarmModelTable entries are created, how are the values for the various columns supplied? 3) if an alarmModelEntry is deleted, what happens to the corresponding ituAlarmModelEntries (since it's a one-to-many relationship due to ituAlarmPerceivedSeverity, I assume they will always appear and disappear six at a time.) Does this help to explain why I'd like the DESCRIPTIONs to better explain what's going on with this table? Randy From disman-admin@ietf.org Tue Oct 7 15:25:24 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 PAA18589 for ; Tue, 7 Oct 2003 15:25:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xSA-0001vY-Fe; Tue, 07 Oct 2003 15:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xS4-0001v7-Jh for disman@optimus.ietf.org; Tue, 07 Oct 2003 15:24:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18570 for ; Tue, 7 Oct 2003 15:24:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6xS3-0002Sx-00 for disman@ietf.org; Tue, 07 Oct 2003 15:24:55 -0400 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by ietf-mx with esmtp (Exim 4.12) id 1A6xS2-0002Su-00 for disman@ietf.org; Tue, 07 Oct 2003 15:24:54 -0400 Received: from h-68-165-66-37.snvacaid.dynamic.covad.net ([68.165.66.37] helo=oemcomputer) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A6xS1-0003SX-00 for disman@ietf.org; Tue, 07 Oct 2003 12:24:53 -0700 Message-ID: <002101c38d08$b693cc20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] ituAlarmGenericModel is redundant? 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, 7 Oct 2003 12:25:05 -0700 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 ... > 68) ituAlarmGenericModel: why is this object needed? the indexing > information needed to find the model entry is the same for both > tables. ... ituAlarmGenericModel seems comepletely redundant. All the information needed to find the alarmModelEntry corresponding to an ituAlarmEntry is already present in that entry's indexes. This object serves no purpose. Proposal: remove ituAlarmGenericModel. Randy From exim@www1.ietf.org Tue Oct 7 15:25: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 PAA18604 for ; Tue, 7 Oct 2003 15:25:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xSC-0001xW-Ai for disman-archive@odin.ietf.org; Tue, 07 Oct 2003 15:25:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97JP4qG007524 for disman-archive@odin.ietf.org; Tue, 7 Oct 2003 15:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xSC-0001xH-33 for disman-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 15:25:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18580 for ; Tue, 7 Oct 2003 15:24:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6xSA-0002TD-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 15:25:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6xS9-0002T7-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 15:25:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xSA-0001vY-Fe; Tue, 07 Oct 2003 15:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xS4-0001v7-Jh for disman@optimus.ietf.org; Tue, 07 Oct 2003 15:24:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18570 for ; Tue, 7 Oct 2003 15:24:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6xS3-0002Sx-00 for disman@ietf.org; Tue, 07 Oct 2003 15:24:55 -0400 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by ietf-mx with esmtp (Exim 4.12) id 1A6xS2-0002Su-00 for disman@ietf.org; Tue, 07 Oct 2003 15:24:54 -0400 Received: from h-68-165-66-37.snvacaid.dynamic.covad.net ([68.165.66.37] helo=oemcomputer) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A6xS1-0003SX-00 for disman@ietf.org; Tue, 07 Oct 2003 12:24:53 -0700 Message-ID: <002101c38d08$b693cc20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] ituAlarmGenericModel is redundant? 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, 7 Oct 2003 12:25:05 -0700 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 ... > 68) ituAlarmGenericModel: why is this object needed? the indexing > information needed to find the model entry is the same for both > tables. ... ituAlarmGenericModel seems comepletely redundant. All the information needed to find the alarmModelEntry corresponding to an ituAlarmEntry is already present in that entry's indexes. This object serves no purpose. Proposal: remove ituAlarmGenericModel. Randy From disman-admin@ietf.org Tue Oct 7 15:27: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 PAA18651 for ; Tue, 7 Oct 2003 15:27:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xU5-00023s-72; Tue, 07 Oct 2003 15:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xTS-00021c-4z for disman@optimus.ietf.org; Tue, 07 Oct 2003 15:26:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18635 for ; Tue, 7 Oct 2003 15:26:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6xTQ-0002Tz-00 for disman@ietf.org; Tue, 07 Oct 2003 15:26:20 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A6xTP-0002Tf-00 for disman@ietf.org; Tue, 07 Oct 2003 15:26:19 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h97JPlP01535 for ; Tue, 7 Oct 2003 15:25:47 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 15:24:03 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D27FEB@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] ResourceID TC 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, 7 Oct 2003 15:24:02 -0400 Hi When someone builds a 'do over' machine, the inaccessibility of table indices is definitely on my 'to do' list. The following is the proposed resolution to Randy-43. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the definition of ResourceId, replace " For example, if this resource is an interface, this object MUST point to an ifIndex and if this resource is a physical entity, then this MUST point to an entPhysicalIndex. In general, pointing to objects that act as index into an IETF MIB tables for the resource will provide the most consistency." With " For example, if this resource is an interface, this object MUST point to an ifIndex and if this resource is a physical entity, then this MUST point to an entPhysicalDescr, given that entPhysicalIndex is not accessible. In general, the value is the name of the instance of the first accessible columnar object in the conceptual row of a table that is meaningful for this resource type, which SHOULD be defined in an IETF standard MIB." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 01, 2003 7:51 PM To: Disman (E-mail) Subject: [Disman] ResourceID TC in 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 ... > 43) page 15 (ResourceId): I agree with the intent of the last > sentence in the description, but if there is a MUST requirement > here, how do we ensure that implementations know what to choose > for any arbitrary table? > > Sharon -> I added this, but I probably should not have. I guess we can > consider it clarifying editorial in nature. ... What's there now is (still) problematic. Specifically: For example, if this resource is an interface, this object MUST point to an ifIndex and if this resource is a physical entity, then this MUST point to an entPhysicalIndex. In general, pointing to objects that act as index into an IETF MIB tables for the resource will provide the most consistency." I see two problems: 1) entPhysicalIndex is not-accessible 2) no guidance is given as to which element of a row should be chosen I suggest borrowing from the description of RowPointer in RFC 2579. Randy From disman-admin@ietf.org Tue Oct 7 15:45: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 PAA19193 for ; Tue, 7 Oct 2003 15:45:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xlV-0002zO-ET; Tue, 07 Oct 2003 15:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xkv-0002yo-Jb for disman@optimus.ietf.org; Tue, 07 Oct 2003 15:44:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19168 for ; Tue, 7 Oct 2003 15:44:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6xks-0002em-00 for disman@ietf.org; Tue, 07 Oct 2003 15:44:22 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A6xkr-0002eh-00 for disman@ietf.org; Tue, 07 Oct 2003 15:44:21 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h97JhnZ02407 for ; Tue, 7 Oct 2003 15:43:49 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 15:43:49 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D28044@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38D0B.5418A4E6" Subject: [Disman] Alarm MIB Cut and Paste Error in SMI 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, 7 Oct 2003 15:43:49 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38D0B.5418A4E6 Content-Type: text/plain Hi I've just noticed that in -15, I accidentally paste 'alarmModelVarbindIndex' over 'alarmModelVarbindValue' within the SMI. This will be fixed in -16 Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada ------_=_NextPart_001_01C38D0B.5418A4E6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Alarm MIB Cut and Paste Error in SMI

Hi

I've just noticed that in -15, I accidentally paste = 'alarmModelVarbindIndex' over  'alarmModelVarbindValue' within the = SMI.  This will be fixed in -16

Sharon Chisholm
Portfolio Integration
Nortel Networks
Ottawa, Canada

------_=_NextPart_001_01C38D0B.5418A4E6-- From exim@www1.ietf.org Tue Oct 7 15:45: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 PAA19208 for ; Tue, 7 Oct 2003 15:45:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xlY-00032O-SW for disman-archive@odin.ietf.org; Tue, 07 Oct 2003 15:45:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97Jj4Ib011670 for disman-archive@odin.ietf.org; Tue, 7 Oct 2003 15:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xlY-000329-OJ for disman-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 15:45:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19186 for ; Tue, 7 Oct 2003 15:44:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6xlX-0002fD-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 15:45:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6xlW-0002fA-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 15:45:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xlV-0002zO-ET; Tue, 07 Oct 2003 15:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xkv-0002yo-Jb for disman@optimus.ietf.org; Tue, 07 Oct 2003 15:44:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19168 for ; Tue, 7 Oct 2003 15:44:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6xks-0002em-00 for disman@ietf.org; Tue, 07 Oct 2003 15:44:22 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A6xkr-0002eh-00 for disman@ietf.org; Tue, 07 Oct 2003 15:44:21 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h97JhnZ02407 for ; Tue, 7 Oct 2003 15:43:49 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 15:43:49 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D28044@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38D0B.5418A4E6" Subject: [Disman] Alarm MIB Cut and Paste Error in SMI 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, 7 Oct 2003 15:43:49 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38D0B.5418A4E6 Content-Type: text/plain Hi I've just noticed that in -15, I accidentally paste 'alarmModelVarbindIndex' over 'alarmModelVarbindValue' within the SMI. This will be fixed in -16 Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada ------_=_NextPart_001_01C38D0B.5418A4E6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Alarm MIB Cut and Paste Error in SMI

Hi

I've just noticed that in -15, I accidentally paste = 'alarmModelVarbindIndex' over  'alarmModelVarbindValue' within the = SMI.  This will be fixed in -16

Sharon Chisholm
Portfolio Integration
Nortel Networks
Ottawa, Canada

------_=_NextPart_001_01C38D0B.5418A4E6-- From disman-admin@ietf.org Tue Oct 7 16:00:28 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 QAA19993 for ; Tue, 7 Oct 2003 16:00:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6y03-0003vP-Gf; Tue, 07 Oct 2003 16:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xzh-0003uM-KH for disman@optimus.ietf.org; Tue, 07 Oct 2003 15:59:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19913 for ; Tue, 7 Oct 2003 15:59:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6xzf-0002qk-00 for disman@ietf.org; Tue, 07 Oct 2003 15:59:39 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A6xzf-0002qL-00 for disman@ietf.org; Tue, 07 Oct 2003 15:59:39 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h97Jx7O02763 for ; Tue, 7 Oct 2003 15:59:07 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 15:59:07 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D2807E@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Cc: Randy Presuhn Subject: RE: [Disman] compilation errors 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, 7 Oct 2003 15:59:06 -0400 Hi I forgot I made a syntax change and skipped the usual compile and strict syntax checks. Live and learn. The following is the proposed resolution to Randy-N+1. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In Alarm MIB, change default values of { 0 0 } to { { 0 0 }}. Sharon PS I caught the second problem and sent a separate email saying that it will be fixed. -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 01, 2003 9:04 PM To: disman@ietf.org Subject: [Disman] compilation errors in draft-ietf-disman-alarm-mib-15.txt Hi - Just for fun, I tried to compile the latest alarm mib using the smilint@ibr.cs.tu-bs.de service. There are some problems that need to be fixed before this document can procede. For example: - { 0 0 } instead of { { 0 0 } } in some DEFVALs - alarmModelVarbindIndex is defined twice Randy From exim@www1.ietf.org Tue Oct 7 16:00: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 QAA20009 for ; Tue, 7 Oct 2003 16:00:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6y08-0003yU-W7 for disman-archive@odin.ietf.org; Tue, 07 Oct 2003 16:00:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97K08HP015271 for disman-archive@odin.ietf.org; Tue, 7 Oct 2003 16:00:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6y08-0003yC-8d for disman-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 16:00:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19948 for ; Tue, 7 Oct 2003 15:59:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6y05-0002rG-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 16:00:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6y04-0002rD-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 16:00:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6y03-0003vP-Gf; Tue, 07 Oct 2003 16:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xzh-0003uM-KH for disman@optimus.ietf.org; Tue, 07 Oct 2003 15:59:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19913 for ; Tue, 7 Oct 2003 15:59:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6xzf-0002qk-00 for disman@ietf.org; Tue, 07 Oct 2003 15:59:39 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A6xzf-0002qL-00 for disman@ietf.org; Tue, 07 Oct 2003 15:59:39 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h97Jx7O02763 for ; Tue, 7 Oct 2003 15:59:07 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 15:59:07 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D2807E@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org Cc: Randy Presuhn Subject: RE: [Disman] compilation errors 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, 7 Oct 2003 15:59:06 -0400 Hi I forgot I made a syntax change and skipped the usual compile and strict syntax checks. Live and learn. The following is the proposed resolution to Randy-N+1. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In Alarm MIB, change default values of { 0 0 } to { { 0 0 }}. Sharon PS I caught the second problem and sent a separate email saying that it will be fixed. -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 01, 2003 9:04 PM To: disman@ietf.org Subject: [Disman] compilation errors in draft-ietf-disman-alarm-mib-15.txt Hi - Just for fun, I tried to compile the latest alarm mib using the smilint@ibr.cs.tu-bs.de service. There are some problems that need to be fixed before this document can procede. For example: - { 0 0 } instead of { { 0 0 } } in some DEFVALs - alarmModelVarbindIndex is defined twice Randy From exim@www1.ietf.org Tue Oct 7 16:15:34 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 PAA18665 for ; Tue, 7 Oct 2003 15:27:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xU6-00026e-J4 for disman-archive@odin.ietf.org; Tue, 07 Oct 2003 15:27:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97JR2w8008097 for disman-archive@odin.ietf.org; Tue, 7 Oct 2003 15:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xU6-00026W-DX for disman-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 15:27:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18646 for ; Tue, 7 Oct 2003 15:26:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6xU4-0002UC-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 15:27:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6xU4-0002U8-00 for disman-web-archive@ietf.org; Tue, 07 Oct 2003 15:27:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xU5-00023s-72; Tue, 07 Oct 2003 15:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6xTS-00021c-4z for disman@optimus.ietf.org; Tue, 07 Oct 2003 15:26:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18635 for ; Tue, 7 Oct 2003 15:26:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6xTQ-0002Tz-00 for disman@ietf.org; Tue, 07 Oct 2003 15:26:20 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A6xTP-0002Tf-00 for disman@ietf.org; Tue, 07 Oct 2003 15:26:19 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h97JPlP01535 for ; Tue, 7 Oct 2003 15:25:47 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 15:24:03 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D27FEB@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] ResourceID TC 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, 7 Oct 2003 15:24:02 -0400 Hi When someone builds a 'do over' machine, the inaccessibility of table indices is definitely on my 'to do' list. The following is the proposed resolution to Randy-43. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the definition of ResourceId, replace " For example, if this resource is an interface, this object MUST point to an ifIndex and if this resource is a physical entity, then this MUST point to an entPhysicalIndex. In general, pointing to objects that act as index into an IETF MIB tables for the resource will provide the most consistency." With " For example, if this resource is an interface, this object MUST point to an ifIndex and if this resource is a physical entity, then this MUST point to an entPhysicalDescr, given that entPhysicalIndex is not accessible. In general, the value is the name of the instance of the first accessible columnar object in the conceptual row of a table that is meaningful for this resource type, which SHOULD be defined in an IETF standard MIB." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 01, 2003 7:51 PM To: Disman (E-mail) Subject: [Disman] ResourceID TC in 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 ... > 43) page 15 (ResourceId): I agree with the intent of the last > sentence in the description, but if there is a MUST requirement > here, how do we ensure that implementations know what to choose > for any arbitrary table? > > Sharon -> I added this, but I probably should not have. I guess we can > consider it clarifying editorial in nature. ... What's there now is (still) problematic. Specifically: For example, if this resource is an interface, this object MUST point to an ifIndex and if this resource is a physical entity, then this MUST point to an entPhysicalIndex. In general, pointing to objects that act as index into an IETF MIB tables for the resource will provide the most consistency." I see two problems: 1) entPhysicalIndex is not-accessible 2) no guidance is given as to which element of a row should be chosen I suggest borrowing from the description of RowPointer in RFC 2579. Randy From disman-admin@ietf.org Wed Oct 8 08:53: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 IAA12415 for ; Wed, 8 Oct 2003 08:53:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7DoK-0003mN-Qe; Wed, 08 Oct 2003 08:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Dng-0003m2-Dr for disman@optimus.ietf.org; Wed, 08 Oct 2003 08:52:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12375 for ; Wed, 8 Oct 2003 08:52:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Dnf-0004Sx-00 for disman@ietf.org; Wed, 08 Oct 2003 08:52:19 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7Dne-0004ST-00 for disman@ietf.org; Wed, 08 Oct 2003 08:52:18 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98CpjL18604 for ; Wed, 8 Oct 2003 08:51:46 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 08:51:46 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D28336@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn 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, 8 Oct 2003 08:51:44 -0400 Hi The following is the proposed resolution to Randy-55. Assuming no objection, this item will is closed with no changes to the draft. It was design intent to prevent the deletion of alarm models while there were active alarms using that model. Randy has indicated that he is OK with not specifying an amount of time before entries are deleted. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 01, 2003 9:35 PM To: Disman (E-mail) Subject: [Disman] unthrottleable alarm state change notifications 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 ... > 55) alarmModelRowStatus does not permit modification of a > model while active alarms exist. This would seem to create > the possibility of "un-throttle-able" alarm storms, contrary > to the spirit of draft-ietf-ops-mib-review-guidelines-01.txt > section 4.7 last paragraph. ... The updated text is still problematic. Specifically, this text remains: This row can not be modified or deleted while it is being referenced by a value of alarmActiveModelPointer. In these As long as there is an active alarm referencing the model, one would not be able to take action using this MIB to throttle it. Also, the entry removal text doesn't specify a lifetime, and the famous five minutes in 2579 are only a suggestion, so the current text really leaves it up to the implementation. This is OK with me, but I want to be sure it's what is intended. Randy From exim@www1.ietf.org Wed Oct 8 08:53: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 IAA12430 for ; Wed, 8 Oct 2003 08:53:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7DoQ-0003n5-3W for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 08:53:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Cr63X014569 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 08:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7DoQ-0003mu-0R for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 08:53:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12411 for ; Wed, 8 Oct 2003 08:52:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7DoO-0004TQ-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 08:53:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7DoO-0004TM-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 08:53:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7DoK-0003mN-Qe; Wed, 08 Oct 2003 08:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Dng-0003m2-Dr for disman@optimus.ietf.org; Wed, 08 Oct 2003 08:52:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12375 for ; Wed, 8 Oct 2003 08:52:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Dnf-0004Sx-00 for disman@ietf.org; Wed, 08 Oct 2003 08:52:19 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7Dne-0004ST-00 for disman@ietf.org; Wed, 08 Oct 2003 08:52:18 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98CpjL18604 for ; Wed, 8 Oct 2003 08:51:46 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 08:51:46 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D28336@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn 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, 8 Oct 2003 08:51:44 -0400 Hi The following is the proposed resolution to Randy-55. Assuming no objection, this item will is closed with no changes to the draft. It was design intent to prevent the deletion of alarm models while there were active alarms using that model. Randy has indicated that he is OK with not specifying an amount of time before entries are deleted. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 01, 2003 9:35 PM To: Disman (E-mail) Subject: [Disman] unthrottleable alarm state change notifications 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 ... > 55) alarmModelRowStatus does not permit modification of a > model while active alarms exist. This would seem to create > the possibility of "un-throttle-able" alarm storms, contrary > to the spirit of draft-ietf-ops-mib-review-guidelines-01.txt > section 4.7 last paragraph. ... The updated text is still problematic. Specifically, this text remains: This row can not be modified or deleted while it is being referenced by a value of alarmActiveModelPointer. In these As long as there is an active alarm referencing the model, one would not be able to take action using this MIB to throttle it. Also, the entry removal text doesn't specify a lifetime, and the famous five minutes in 2579 are only a suggestion, so the current text really leaves it up to the implementation. This is OK with me, but I want to be sure it's what is intended. Randy From disman-admin@ietf.org Wed Oct 8 13:43:34 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 NAA28986 for ; Wed, 8 Oct 2003 13:43:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IL0-0005kJ-1o; Wed, 08 Oct 2003 13:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IKX-0005i8-OY for disman@optimus.ietf.org; Wed, 08 Oct 2003 13:42:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28931 for ; Wed, 8 Oct 2003 13:42:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7IKV-0001fs-00 for disman@ietf.org; Wed, 08 Oct 2003 13:42:31 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A7IKU-0001fp-00 for disman@ietf.org; Wed, 08 Oct 2003 13:42:30 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7IKS-0003z3-00 for disman@ietf.org; Wed, 08 Oct 2003 10:42:28 -0700 Message-ID: <00ea01c38dc3$92a2fc80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D28336@zcard0ka.ca.nortel.com> Subject: Re: [Disman] unthrottleable alarm state change notifications 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: Wed, 8 Oct 2003 10:42:40 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 5:51 AM > Subject: RE: [Disman] unthrottleable alarm state change notifications ... > It was design intent to prevent the deletion of alarm models while there > were active alarms using that model. ... Is no one else bothered by the behavior this design produces? - manager (mistakenly) creates alarm model that matches some frequent event from a large number of sources (e.g., process creation or connection attempt) - zillions of alarms are created - manager, realizing mistake, can't shut it down: - cannot modify alarmModelEntry attributes to correct mistake - cannot delete alarmModelEntry - the alarm model entry persists, so even re-booting the system won't fix the problem There's an even simpler failure mode: - manager creates an alarm model, but the "clear" entry refers to an event that will never happen, perhaps due to a typo, or perhaps due to the way the managed system works - one (or more alarms) created - there is no way to clear these alarms - there is no way to get rid of the erroneous alarm model If this is really what the WG wants, the chair will let it go, but this technical contributor thinks its a big mistake. If there's an error in my reasoning here, please elucidate. Randy From disman-admin@ietf.org Wed Oct 8 13:43:34 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 NAA28985 for ; Wed, 8 Oct 2003 13:43:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IKz-0005jb-5G; Wed, 08 Oct 2003 13:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IKL-0005hc-GL for disman@optimus.ietf.org; Wed, 08 Oct 2003 13:42:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28907 for ; Wed, 8 Oct 2003 13:42:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7IKJ-0001fQ-00 for disman@ietf.org; Wed, 08 Oct 2003 13:42:19 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A7IKI-0001eq-00 for disman@ietf.org; Wed, 08 Oct 2003 13:42:18 -0400 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 h98HfeB25341 for ; Wed, 8 Oct 2003 13:41:40 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 13:41:41 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D28783@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm M IB 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, 8 Oct 2003 13:41:39 -0400 Hi I've divided this up into Liaison content and Liaison Process 1) Content Sharon previously said: "Thank you for the interest in the Alarm MIB. The Distributed Management (disman) working group hopes to advance the current I-D to Proposed Standard, with minimal editorial changes. In the future, if the working group is chartered with an Alarm MIB version 2, we will be interested in cooperating with you to ensure your requirements are considered." Randy said: "I'd like to make it clear that (as far as I know) we've addressed all their comments. Regarding possible future work, I'd prefer a broader statement. How about "We welcome your input on any disman work items, including discussions of possible future work"?" Sharon today says-> Actually, we sent a previous, informal, liaison to indicate we addressed there concerns. This is in response to a subsequent liaison where they suggested enhancements for a future version of the Alarm MIB. See slide 5 of http://www.ietf.org/proceedings/03mar/slides/disman-2/index.html Randy also said: "Let's use http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt as our guide for form and process, and inform its authors if we run into any problems. So, let's at least include the necessary boilerplate items." Kam said: "Also inform SG4 about the current status of the I-D and provide the URL of the latest version." So, how about: " From: IETF Disman Working Group To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 Title: Response to Liaison on Alarm MIB Response Contact: Randy Presuhn Technical Contact: disman@ietf.org Purpose: In Replay to Liaison Thank you for the interest in the Alarm MIB. The latest version is currently completed Area Director Review and can be found at http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt The Distributed Management (disman) working group hopes to advance the current I-D to Proposed Standard, with minimal editorial changes. In the future, if the working group is chartered with an Alarm MIB version 2, we will be interested in cooperating with you to ensure your requirements are considered." 2) Process Randy said: "Let's see how http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt works." There is discussion about a web page that I can't find. Any Ideas? Sharon From exim@www1.ietf.org Wed Oct 8 13:43:35 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 NAA29015 for ; Wed, 8 Oct 2003 13:43:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ILC-0005nz-1Q for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 13:43:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98HhDDc022308 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 13:43:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ILB-0005nV-SF for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 13:43:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28940 for ; Wed, 8 Oct 2003 13:43:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7IL9-0001gx-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 13:43:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7IL9-0001gr-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 13:43:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IL0-0005kJ-1o; Wed, 08 Oct 2003 13:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IKX-0005i8-OY for disman@optimus.ietf.org; Wed, 08 Oct 2003 13:42:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28931 for ; Wed, 8 Oct 2003 13:42:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7IKV-0001fs-00 for disman@ietf.org; Wed, 08 Oct 2003 13:42:31 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A7IKU-0001fp-00 for disman@ietf.org; Wed, 08 Oct 2003 13:42:30 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7IKS-0003z3-00 for disman@ietf.org; Wed, 08 Oct 2003 10:42:28 -0700 Message-ID: <00ea01c38dc3$92a2fc80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D28336@zcard0ka.ca.nortel.com> Subject: Re: [Disman] unthrottleable alarm state change notifications 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: Wed, 8 Oct 2003 10:42:40 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 5:51 AM > Subject: RE: [Disman] unthrottleable alarm state change notifications ... > It was design intent to prevent the deletion of alarm models while there > were active alarms using that model. ... Is no one else bothered by the behavior this design produces? - manager (mistakenly) creates alarm model that matches some frequent event from a large number of sources (e.g., process creation or connection attempt) - zillions of alarms are created - manager, realizing mistake, can't shut it down: - cannot modify alarmModelEntry attributes to correct mistake - cannot delete alarmModelEntry - the alarm model entry persists, so even re-booting the system won't fix the problem There's an even simpler failure mode: - manager creates an alarm model, but the "clear" entry refers to an event that will never happen, perhaps due to a typo, or perhaps due to the way the managed system works - one (or more alarms) created - there is no way to clear these alarms - there is no way to get rid of the erroneous alarm model If this is really what the WG wants, the chair will let it go, but this technical contributor thinks its a big mistake. If there's an error in my reasoning here, please elucidate. Randy From exim@www1.ietf.org Wed Oct 8 13:43:36 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 NAA29019 for ; Wed, 8 Oct 2003 13:43:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ILC-0005nq-0C for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 13:43:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98HhDTC022294 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 13:43:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ILB-0005nU-RV for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 13:43:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28939 for ; Wed, 8 Oct 2003 13:43:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7IL9-0001gu-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 13:43:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7IL9-0001gq-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 13:43:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IKz-0005jb-5G; Wed, 08 Oct 2003 13:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IKL-0005hc-GL for disman@optimus.ietf.org; Wed, 08 Oct 2003 13:42:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28907 for ; Wed, 8 Oct 2003 13:42:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7IKJ-0001fQ-00 for disman@ietf.org; Wed, 08 Oct 2003 13:42:19 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A7IKI-0001eq-00 for disman@ietf.org; Wed, 08 Oct 2003 13:42:18 -0400 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 h98HfeB25341 for ; Wed, 8 Oct 2003 13:41:40 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 13:41:41 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D28783@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm M IB 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, 8 Oct 2003 13:41:39 -0400 Hi I've divided this up into Liaison content and Liaison Process 1) Content Sharon previously said: "Thank you for the interest in the Alarm MIB. The Distributed Management (disman) working group hopes to advance the current I-D to Proposed Standard, with minimal editorial changes. In the future, if the working group is chartered with an Alarm MIB version 2, we will be interested in cooperating with you to ensure your requirements are considered." Randy said: "I'd like to make it clear that (as far as I know) we've addressed all their comments. Regarding possible future work, I'd prefer a broader statement. How about "We welcome your input on any disman work items, including discussions of possible future work"?" Sharon today says-> Actually, we sent a previous, informal, liaison to indicate we addressed there concerns. This is in response to a subsequent liaison where they suggested enhancements for a future version of the Alarm MIB. See slide 5 of http://www.ietf.org/proceedings/03mar/slides/disman-2/index.html Randy also said: "Let's use http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt as our guide for form and process, and inform its authors if we run into any problems. So, let's at least include the necessary boilerplate items." Kam said: "Also inform SG4 about the current status of the I-D and provide the URL of the latest version." So, how about: " From: IETF Disman Working Group To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 Title: Response to Liaison on Alarm MIB Response Contact: Randy Presuhn Technical Contact: disman@ietf.org Purpose: In Replay to Liaison Thank you for the interest in the Alarm MIB. The latest version is currently completed Area Director Review and can be found at http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt The Distributed Management (disman) working group hopes to advance the current I-D to Proposed Standard, with minimal editorial changes. In the future, if the working group is chartered with an Alarm MIB version 2, we will be interested in cooperating with you to ensure your requirements are considered." 2) Process Randy said: "Let's see how http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt works." There is discussion about a web page that I can't find. Any Ideas? Sharon From disman-admin@ietf.org Wed Oct 8 13:49: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 NAA29274 for ; Wed, 8 Oct 2003 13:49:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IQn-00068V-RG; Wed, 08 Oct 2003 13:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IQf-00067t-7d for disman@optimus.ietf.org; Wed, 08 Oct 2003 13:48:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29262 for ; Wed, 8 Oct 2003 13:48:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7IQc-0001lJ-00 for disman@ietf.org; Wed, 08 Oct 2003 13:48:50 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7IQb-0001ke-00 for disman@ietf.org; Wed, 08 Oct 2003 13:48:50 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98HmHL07004 for ; Wed, 8 Oct 2003 13:48:17 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 13:48:18 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D28790@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm M IB 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, 8 Oct 2003 13:48:17 -0400 hi Two typos Replay-> Reply Completed-> Completing Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, October 08, 2003 1:42 PM To: Disman (E-mail) Cc: Randy Presuhn Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm M IB Hi I've divided this up into Liaison content and Liaison Process 1) Content Sharon previously said: "Thank you for the interest in the Alarm MIB. The Distributed Management (disman) working group hopes to advance the current I-D to Proposed Standard, with minimal editorial changes. In the future, if the working group is chartered with an Alarm MIB version 2, we will be interested in cooperating with you to ensure your requirements are considered." Randy said: "I'd like to make it clear that (as far as I know) we've addressed all their comments. Regarding possible future work, I'd prefer a broader statement. How about "We welcome your input on any disman work items, including discussions of possible future work"?" Sharon today says-> Actually, we sent a previous, informal, liaison to indicate we addressed there concerns. This is in response to a subsequent liaison where they suggested enhancements for a future version of the Alarm MIB. See slide 5 of http://www.ietf.org/proceedings/03mar/slides/disman-2/index.html Randy also said: "Let's use http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt as our guide for form and process, and inform its authors if we run into any problems. So, let's at least include the necessary boilerplate items." Kam said: "Also inform SG4 about the current status of the I-D and provide the URL of the latest version." So, how about: " From: IETF Disman Working Group To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 Title: Response to Liaison on Alarm MIB Response Contact: Randy Presuhn Technical Contact: disman@ietf.org Purpose: In Replay to Liaison Thank you for the interest in the Alarm MIB. The latest version is currently completed Area Director Review and can be found at http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt The Distributed Management (disman) working group hopes to advance the current I-D to Proposed Standard, with minimal editorial changes. In the future, if the working group is chartered with an Alarm MIB version 2, we will be interested in cooperating with you to ensure your requirements are considered." 2) Process Randy said: "Let's see how http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt works." There is discussion about a web page that I can't find. Any Ideas? Sharon From exim@www1.ietf.org Wed Oct 8 13:49:24 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 NAA29289 for ; Wed, 8 Oct 2003 13:49:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IQo-00069H-RT for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 13:49:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Hn2v8023629 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 13:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IQo-000692-OF for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 13:49:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29267 for ; Wed, 8 Oct 2003 13:48:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7IQm-0001lZ-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 13:49:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7IQm-0001lW-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 13:49:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IQn-00068V-RG; Wed, 08 Oct 2003 13:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IQf-00067t-7d for disman@optimus.ietf.org; Wed, 08 Oct 2003 13:48:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29262 for ; Wed, 8 Oct 2003 13:48:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7IQc-0001lJ-00 for disman@ietf.org; Wed, 08 Oct 2003 13:48:50 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7IQb-0001ke-00 for disman@ietf.org; Wed, 08 Oct 2003 13:48:50 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98HmHL07004 for ; Wed, 8 Oct 2003 13:48:17 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 13:48:18 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D28790@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm M IB 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, 8 Oct 2003 13:48:17 -0400 hi Two typos Replay-> Reply Completed-> Completing Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, October 08, 2003 1:42 PM To: Disman (E-mail) Cc: Randy Presuhn Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm M IB Hi I've divided this up into Liaison content and Liaison Process 1) Content Sharon previously said: "Thank you for the interest in the Alarm MIB. The Distributed Management (disman) working group hopes to advance the current I-D to Proposed Standard, with minimal editorial changes. In the future, if the working group is chartered with an Alarm MIB version 2, we will be interested in cooperating with you to ensure your requirements are considered." Randy said: "I'd like to make it clear that (as far as I know) we've addressed all their comments. Regarding possible future work, I'd prefer a broader statement. How about "We welcome your input on any disman work items, including discussions of possible future work"?" Sharon today says-> Actually, we sent a previous, informal, liaison to indicate we addressed there concerns. This is in response to a subsequent liaison where they suggested enhancements for a future version of the Alarm MIB. See slide 5 of http://www.ietf.org/proceedings/03mar/slides/disman-2/index.html Randy also said: "Let's use http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt as our guide for form and process, and inform its authors if we run into any problems. So, let's at least include the necessary boilerplate items." Kam said: "Also inform SG4 about the current status of the I-D and provide the URL of the latest version." So, how about: " From: IETF Disman Working Group To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 Title: Response to Liaison on Alarm MIB Response Contact: Randy Presuhn Technical Contact: disman@ietf.org Purpose: In Replay to Liaison Thank you for the interest in the Alarm MIB. The latest version is currently completed Area Director Review and can be found at http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt The Distributed Management (disman) working group hopes to advance the current I-D to Proposed Standard, with minimal editorial changes. In the future, if the working group is chartered with an Alarm MIB version 2, we will be interested in cooperating with you to ensure your requirements are considered." 2) Process Randy said: "Let's see how http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt works." There is discussion about a web page that I can't find. Any Ideas? Sharon From disman-admin@ietf.org Wed Oct 8 13:52: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 NAA29458 for ; Wed, 8 Oct 2003 13:52:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ITg-0006JK-CM; Wed, 08 Oct 2003 13:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IT3-0006Es-Ks for disman@optimus.ietf.org; Wed, 08 Oct 2003 13:51:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29436 for ; Wed, 8 Oct 2003 13:51:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7IT1-0001n7-00 for disman@ietf.org; Wed, 08 Oct 2003 13:51:19 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A7IT0-0001n4-00 for disman@ietf.org; Wed, 08 Oct 2003 13:51:18 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7IT0-0003Xe-00 for disman@ietf.org; Wed, 08 Oct 2003 10:51:18 -0700 Message-ID: <00fc01c38dc4$ceb0b720$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D28783@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm MIB X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 8 Oct 2003 10:51:31 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 10:41 AM > Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm MIB ... > From: IETF Disman Working Group > To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 > Title: Response to Liaison on Alarm MIB > Response Contact: Randy Presuhn > Technical Contact: disman@ietf.org > Purpose: In Replay to Liaison > > Thank you for the interest in the Alarm MIB. The latest version is currently > completed Area Director Review and can be found at "completed" -> "under" > > http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt > > The Distributed Management (disman) working group hopes to advance the > current I-D to Proposed Standard, with minimal editorial changes. In the It's not clear to me whether "editorial" is too strong. To avoid misleading anyone, let's remove "editorial" or wait til we've finished the review cycle. > future, if the working group is chartered with an Alarm MIB version 2, we > will be interested in cooperating with you to ensure your requirements are > considered." > > 2) Process > Randy said: > > "Let's see how > http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt > works." > > There is discussion about a web page that I can't find. Any Ideas? ... The automation the i-d talks about isn't in place, as far as I know, but it wouldn't hurt to ask the i-d authors. My intent was that we try to follow the workflow outlined there, so that all the right people are involved in the right sequence, and so that we can provide the i-d authors with useful feedback. Randy From exim@www1.ietf.org Wed Oct 8 13:52: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 NAA29473 for ; Wed, 8 Oct 2003 13:52:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ITh-0006NS-Rm for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 13:52:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Hq1eD024508 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 13:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ITh-0006ND-OP for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 13:52:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29452 for ; Wed, 8 Oct 2003 13:51:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ITf-0001nX-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 13:51:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7ITf-0001nU-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 13:51:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ITg-0006JK-CM; Wed, 08 Oct 2003 13:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IT3-0006Es-Ks for disman@optimus.ietf.org; Wed, 08 Oct 2003 13:51:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29436 for ; Wed, 8 Oct 2003 13:51:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7IT1-0001n7-00 for disman@ietf.org; Wed, 08 Oct 2003 13:51:19 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A7IT0-0001n4-00 for disman@ietf.org; Wed, 08 Oct 2003 13:51:18 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7IT0-0003Xe-00 for disman@ietf.org; Wed, 08 Oct 2003 10:51:18 -0700 Message-ID: <00fc01c38dc4$ceb0b720$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D28783@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm MIB X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 8 Oct 2003 10:51:31 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 10:41 AM > Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm MIB ... > From: IETF Disman Working Group > To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 > Title: Response to Liaison on Alarm MIB > Response Contact: Randy Presuhn > Technical Contact: disman@ietf.org > Purpose: In Replay to Liaison > > Thank you for the interest in the Alarm MIB. The latest version is currently > completed Area Director Review and can be found at "completed" -> "under" > > http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt > > The Distributed Management (disman) working group hopes to advance the > current I-D to Proposed Standard, with minimal editorial changes. In the It's not clear to me whether "editorial" is too strong. To avoid misleading anyone, let's remove "editorial" or wait til we've finished the review cycle. > future, if the working group is chartered with an Alarm MIB version 2, we > will be interested in cooperating with you to ensure your requirements are > considered." > > 2) Process > Randy said: > > "Let's see how > http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt > works." > > There is discussion about a web page that I can't find. Any Ideas? ... The automation the i-d talks about isn't in place, as far as I know, but it wouldn't hurt to ask the i-d authors. My intent was that we try to follow the workflow outlined there, so that all the right people are involved in the right sequence, and so that we can provide the i-d authors with useful feedback. Randy From disman-admin@ietf.org Wed Oct 8 14: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 OAA01019 for ; Wed, 8 Oct 2003 14:20:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Iup-000888-Ky; Wed, 08 Oct 2003 14:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Itv-00086P-Tl for disman@optimus.ietf.org; Wed, 08 Oct 2003 14:19:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00906 for ; Wed, 8 Oct 2003 14:18:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Its-0002Ik-00 for disman@ietf.org; Wed, 08 Oct 2003 14:19:04 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7Its-0002Hh-00 for disman@ietf.org; Wed, 08 Oct 2003 14:19:04 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98IIWL18135 for ; Wed, 8 Oct 2003 14:18:32 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 14:18:33 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D287F4@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] alarmActiveEngineAddress 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, 8 Oct 2003 14:18:30 -0400 Hi The following is the proposed resolution to Randy-58. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the description for alarmActiveEngineAddress, replace " "The Address of the SNMP engine on which the alarm is" With " "The address of the SNMP engine on which the alarm is" No change will be done to address the second observation. The Engine ID object indicates that it identifies the source of the alarm and this indicates it is used when that isn't available. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 01, 2003 9:51 PM To: Disman (E-mail) Subject: [Disman] alarmActiveEngineAddress 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 ... ... > 58) alarmActiveEngineAddress: "IP Address" -> "address" > ditto alarmClearEngineAddress ... One step forward, two steps back. :-) * 0.5 - "Address" should be "address" - the sentence "This is used to identify the source of an SNMPv1 trap, since an alarmActiveEngineId cannot be extracted from the SNMPv1 trap PDU." leaves me wondering why it's there, since even if one can extract an SnmpEngineId from a wrapper, it still won't reliably yield an address. Randy From exim@www1.ietf.org Wed Oct 8 14:20: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 OAA01034 for ; Wed, 8 Oct 2003 14:20:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Iuu-0008Cl-Ir for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 14:20:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98IK85m031529 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 14:20:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Iuu-0008CQ-7x for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 14:20:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00991 for ; Wed, 8 Oct 2003 14:19:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Iur-0002Je-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 14:20:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7Iuq-0002Ja-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 14:20:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Iup-000888-Ky; Wed, 08 Oct 2003 14:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Itv-00086P-Tl for disman@optimus.ietf.org; Wed, 08 Oct 2003 14:19:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00906 for ; Wed, 8 Oct 2003 14:18:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Its-0002Ik-00 for disman@ietf.org; Wed, 08 Oct 2003 14:19:04 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7Its-0002Hh-00 for disman@ietf.org; Wed, 08 Oct 2003 14:19:04 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98IIWL18135 for ; Wed, 8 Oct 2003 14:18:32 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 14:18:33 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D287F4@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] alarmActiveEngineAddress 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, 8 Oct 2003 14:18:30 -0400 Hi The following is the proposed resolution to Randy-58. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the description for alarmActiveEngineAddress, replace " "The Address of the SNMP engine on which the alarm is" With " "The address of the SNMP engine on which the alarm is" No change will be done to address the second observation. The Engine ID object indicates that it identifies the source of the alarm and this indicates it is used when that isn't available. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 01, 2003 9:51 PM To: Disman (E-mail) Subject: [Disman] alarmActiveEngineAddress 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 ... ... > 58) alarmActiveEngineAddress: "IP Address" -> "address" > ditto alarmClearEngineAddress ... One step forward, two steps back. :-) * 0.5 - "Address" should be "address" - the sentence "This is used to identify the source of an SNMPv1 trap, since an alarmActiveEngineId cannot be extracted from the SNMPv1 trap PDU." leaves me wondering why it's there, since even if one can extract an SnmpEngineId from a wrapper, it still won't reliably yield an address. Randy From disman-admin@ietf.org Wed Oct 8 14:52: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 OAA02534 for ; Wed, 8 Oct 2003 14:52:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JPk-0001mM-U8; Wed, 08 Oct 2003 14:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JPQ-0001ld-Qo for disman@optimus.ietf.org; Wed, 08 Oct 2003 14:51:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02500 for ; Wed, 8 Oct 2003 14:51:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7JPN-0002kT-00 for disman@ietf.org; Wed, 08 Oct 2003 14:51:37 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7JPN-0002kG-00 for disman@ietf.org; Wed, 08 Oct 2003 14:51:37 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98Ip5L23178 for ; Wed, 8 Oct 2003 14:51:06 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 14:51:05 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D2886B@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] alarmModelRowStatus 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, 8 Oct 2003 14:51:04 -0400 hi The following is the proposed resolution to Randy-49. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. Add the following text to the description of alarmModelRowStatus: As all read-create objects in this table have a DEFVAL clause, there is no requirement that any object be explicitly set before this row can become active. Note that a row consisting only of default values is not very meaningful." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 03, 2003 10:40 PM To: Disman (E-mail) Subject: Re: [Disman] alarmModelRowStatus Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Romascanu, Dan (Dan)" ; "Randy Presuhn" > > Sent: Friday, October 03, 2003 1:10 PM > Subject: RE: [Disman] alarmModelRowStatus ... > We have a proposed resolution to Randy-49 - since all objects in the > table have default values, no further changes are required. > > Objections? ... Yes. As MIB reviewer, I must point out yet again that the MIB review guidelines require us to specify "which columnar objects (if any) have to be set." Dan's comments (or something to similar effect) need to be reflected in the DESCRIPTION. Randy From exim@www1.ietf.org Wed Oct 8 14:52:28 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 OAA02549 for ; Wed, 8 Oct 2003 14:52:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JPs-0001o5-5q for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 14:52:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Iq854006939 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 14:52:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JPs-0001nq-2H for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 14:52:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02518 for ; Wed, 8 Oct 2003 14:51:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7JPp-0002kv-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 14:52:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7JPo-0002ks-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 14:52:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JPk-0001mM-U8; Wed, 08 Oct 2003 14:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JPQ-0001ld-Qo for disman@optimus.ietf.org; Wed, 08 Oct 2003 14:51:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02500 for ; Wed, 8 Oct 2003 14:51:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7JPN-0002kT-00 for disman@ietf.org; Wed, 08 Oct 2003 14:51:37 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7JPN-0002kG-00 for disman@ietf.org; Wed, 08 Oct 2003 14:51:37 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98Ip5L23178 for ; Wed, 8 Oct 2003 14:51:06 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 14:51:05 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D2886B@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] alarmModelRowStatus 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, 8 Oct 2003 14:51:04 -0400 hi The following is the proposed resolution to Randy-49. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. Add the following text to the description of alarmModelRowStatus: As all read-create objects in this table have a DEFVAL clause, there is no requirement that any object be explicitly set before this row can become active. Note that a row consisting only of default values is not very meaningful." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 03, 2003 10:40 PM To: Disman (E-mail) Subject: Re: [Disman] alarmModelRowStatus Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Romascanu, Dan (Dan)" ; "Randy Presuhn" > > Sent: Friday, October 03, 2003 1:10 PM > Subject: RE: [Disman] alarmModelRowStatus ... > We have a proposed resolution to Randy-49 - since all objects in the > table have default values, no further changes are required. > > Objections? ... Yes. As MIB reviewer, I must point out yet again that the MIB review guidelines require us to specify "which columnar objects (if any) have to be set." Dan's comments (or something to similar effect) need to be reflected in the DESCRIPTION. Randy From disman-admin@ietf.org Wed Oct 8 15:02: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 PAA02978 for ; Wed, 8 Oct 2003 15:02:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JZS-0002ST-8b; Wed, 08 Oct 2003 15:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JZM-0002O8-Ap for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:01:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02955 for ; Wed, 8 Oct 2003 15:01:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7JZJ-0002sB-00 for disman@ietf.org; Wed, 08 Oct 2003 15:01:53 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A7JZI-0002ro-00 for disman@ietf.org; Wed, 08 Oct 2003 15:01:52 -0400 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 h98J1LB16229 for ; Wed, 8 Oct 2003 15:01:21 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 15:01:20 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D28899@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn 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: Wed, 8 Oct 2003 15:01:18 -0400 Hi The following is the proposed resolution to Randy-65. Assuming no objection, this item will is closed with no changes to the draft. Section 4.1.1 says "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." Therefore the distinction that Randy is making is a moot point. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 02, 2003 6:32 PM To: Disman (E-mail) Subject: [Disman] Section 5.1 in 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 ... > 65) 5.1: "about alarms" -> "about alarms modeled using the ituAlarmTable" > "total alarms" -> "total alarms modeled using the ituAlarmTable" ... Though this item is identified as "changed", it looks like it only got half done. As it stands, I think this sentence is still incorrect: The ituAlarmActiveStatsTable provides statistics on current and total alarms. The number is the total for stuff modeled using the ituAlarmTable, not total alarms in the system, right? Randy From exim@www1.ietf.org Wed Oct 8 15:02: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 PAA02992 for ; Wed, 8 Oct 2003 15:02:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JZU-0002UA-Ik for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 15:02:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98J24p1009546 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 15:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JZU-0002Tt-ET for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 15:02:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02959 for ; Wed, 8 Oct 2003 15:01:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7JZR-0002sI-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:02:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7JZR-0002sF-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:02:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JZS-0002ST-8b; Wed, 08 Oct 2003 15:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JZM-0002O8-Ap for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:01:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02955 for ; Wed, 8 Oct 2003 15:01:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7JZJ-0002sB-00 for disman@ietf.org; Wed, 08 Oct 2003 15:01:53 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A7JZI-0002ro-00 for disman@ietf.org; Wed, 08 Oct 2003 15:01:52 -0400 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 h98J1LB16229 for ; Wed, 8 Oct 2003 15:01:21 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 15:01:20 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D28899@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn 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: Wed, 8 Oct 2003 15:01:18 -0400 Hi The following is the proposed resolution to Randy-65. Assuming no objection, this item will is closed with no changes to the draft. Section 4.1.1 says "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." Therefore the distinction that Randy is making is a moot point. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 02, 2003 6:32 PM To: Disman (E-mail) Subject: [Disman] Section 5.1 in 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 ... > 65) 5.1: "about alarms" -> "about alarms modeled using the ituAlarmTable" > "total alarms" -> "total alarms modeled using the ituAlarmTable" ... Though this item is identified as "changed", it looks like it only got half done. As it stands, I think this sentence is still incorrect: The ituAlarmActiveStatsTable provides statistics on current and total alarms. The number is the total for stuff modeled using the ituAlarmTable, not total alarms in the system, right? Randy From disman-admin@ietf.org Wed Oct 8 15:07:22 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 PAA03496 for ; Wed, 8 Oct 2003 15:07:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JeH-0002l2-Em; Wed, 08 Oct 2003 15:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JdM-0002jY-EO for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:06:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03330 for ; Wed, 8 Oct 2003 15:05:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7JdJ-0002vq-00 for disman@ietf.org; Wed, 08 Oct 2003 15:06:01 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7JdI-0002vg-00 for disman@ietf.org; Wed, 08 Oct 2003 15:06:00 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7JdG-0007N8-00 for disman@ietf.org; Wed, 08 Oct 2003 12:05:58 -0700 Message-ID: <000401c38dcf$3d021840$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] alarmListName implications 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, 8 Oct 2003 12:06:11 -0700 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 ... > 56) alarmListName's DESCRIPTION should spell how this object's > value hooks into the SNMP-NOTIFICATION-MIB. Without out this > bit of explanation, the whole thing is magic. It's good that it explains the non-normative relationship to nlmLogName. However, it's more important that it also be explicit about the fact that the notification got here by matching an RFC 3413 snmpNotifyFilterProfileName, since that's the mechanism for selecting the notifications in the first place, as sketched out in the diagram in section 3.2 > 60) alarmActiveLogPointer: should spell out that the log's name > would be the same as alarmListName for this instance. > ditto alarmClearLogIndex I'll relent on this one, since adequate text for (56) would make this redundant. > 75-1) Section 7 should describe the need for security administrators to > configure a coherent VACM policy for the configuration of the > SNMP-NOTIFICATION-MIB, the log MIB, and these MIBs based on log name. > > Sharon->We agreed back when everyone was complaining about the > Sharon->notification log MIB to not tie this document to it. The goal agree we don't need a normative reference > Sharon->was to be able to support it and any other log. ... That wasn't the reasoning as I recall it. The problem was that the initial versions of this tied alarms to log entries, and the life-cycle of a log entry may be different from that of an alarm. Anway, that's not the issue. This is *not* a question of making a normative reference to the log MIB. Rather, it's about explaining how this MIB is meant to be used. We've seen enough complaints that I'd prefer to err on the side of being overly clear. The relationship between RFC 3014's nlmLogName and RFC 3413's snmpNotifyFilterProfileName (particularly since 3014 calls it snmpNotifyFilterName) is practically an FAQ, even though 3014 2.2.1 spells it out. The -15- i-d only hints at the relationship in the diagram in section 3.2 For item 75-1, the issues are similar to those we faced when we did the log MIB: how to design the MIB and write the security considerations section so that we didn't "leak" information. To me, this means providing a modicum of guidance to security administrators in the security considerations section so that this MIB can be used with reasonable safety. The relationship between nlmLogName, snmpNotifyFilterProfileName, and alarmListName is deliberately chosen to make life easier for the security administrator. Proposed words to add to security considerations: "This MIB module can provide access to information that may also be accessed through manipulation of the SNMP-NOTIFICATION-MIB and the NOTIFICATION-LOG-MIB. This is expressed in part through the common indexing structure of nlmLogName [RFC3014], snmpNotifyFilterProfileName [RFC3413], and alarmListName. Consequently, it is RECOMMENDED that security administrators take care to configure a coherent VACM security policy. The objects alarmActiveLogPointer, alarmActiveModelPointer, alarmActiveSpecificPointer, and alarmClearModelPointer are object identifiers that reference information to which a particular user might not be given direct access. The structure of these object identifiers does not permit the extraction of any sensitive information. Two other objects, alarmClearResourceId, and alarmActiveResourceId, are also syntactically object identifiers, but their structure could provide a user with potentially useful information to which he or she might not otherwise be granted access, such as the existence of a particular resource." Whew. Randy From exim@www1.ietf.org Wed Oct 8 15:07:24 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 PAA03513 for ; Wed, 8 Oct 2003 15:07:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JeK-0002ni-7p for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 15:07:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98J7399010751 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 15:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JeJ-0002n6-Jl for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 15:07:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03439 for ; Wed, 8 Oct 2003 15:06:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7JeG-0002wa-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:07:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7JeF-0002wW-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:06:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JeH-0002l2-Em; Wed, 08 Oct 2003 15:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JdM-0002jY-EO for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:06:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03330 for ; Wed, 8 Oct 2003 15:05:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7JdJ-0002vq-00 for disman@ietf.org; Wed, 08 Oct 2003 15:06:01 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7JdI-0002vg-00 for disman@ietf.org; Wed, 08 Oct 2003 15:06:00 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7JdG-0007N8-00 for disman@ietf.org; Wed, 08 Oct 2003 12:05:58 -0700 Message-ID: <000401c38dcf$3d021840$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] alarmListName implications 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, 8 Oct 2003 12:06:11 -0700 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 ... > 56) alarmListName's DESCRIPTION should spell how this object's > value hooks into the SNMP-NOTIFICATION-MIB. Without out this > bit of explanation, the whole thing is magic. It's good that it explains the non-normative relationship to nlmLogName. However, it's more important that it also be explicit about the fact that the notification got here by matching an RFC 3413 snmpNotifyFilterProfileName, since that's the mechanism for selecting the notifications in the first place, as sketched out in the diagram in section 3.2 > 60) alarmActiveLogPointer: should spell out that the log's name > would be the same as alarmListName for this instance. > ditto alarmClearLogIndex I'll relent on this one, since adequate text for (56) would make this redundant. > 75-1) Section 7 should describe the need for security administrators to > configure a coherent VACM policy for the configuration of the > SNMP-NOTIFICATION-MIB, the log MIB, and these MIBs based on log name. > > Sharon->We agreed back when everyone was complaining about the > Sharon->notification log MIB to not tie this document to it. The goal agree we don't need a normative reference > Sharon->was to be able to support it and any other log. ... That wasn't the reasoning as I recall it. The problem was that the initial versions of this tied alarms to log entries, and the life-cycle of a log entry may be different from that of an alarm. Anway, that's not the issue. This is *not* a question of making a normative reference to the log MIB. Rather, it's about explaining how this MIB is meant to be used. We've seen enough complaints that I'd prefer to err on the side of being overly clear. The relationship between RFC 3014's nlmLogName and RFC 3413's snmpNotifyFilterProfileName (particularly since 3014 calls it snmpNotifyFilterName) is practically an FAQ, even though 3014 2.2.1 spells it out. The -15- i-d only hints at the relationship in the diagram in section 3.2 For item 75-1, the issues are similar to those we faced when we did the log MIB: how to design the MIB and write the security considerations section so that we didn't "leak" information. To me, this means providing a modicum of guidance to security administrators in the security considerations section so that this MIB can be used with reasonable safety. The relationship between nlmLogName, snmpNotifyFilterProfileName, and alarmListName is deliberately chosen to make life easier for the security administrator. Proposed words to add to security considerations: "This MIB module can provide access to information that may also be accessed through manipulation of the SNMP-NOTIFICATION-MIB and the NOTIFICATION-LOG-MIB. This is expressed in part through the common indexing structure of nlmLogName [RFC3014], snmpNotifyFilterProfileName [RFC3413], and alarmListName. Consequently, it is RECOMMENDED that security administrators take care to configure a coherent VACM security policy. The objects alarmActiveLogPointer, alarmActiveModelPointer, alarmActiveSpecificPointer, and alarmClearModelPointer are object identifiers that reference information to which a particular user might not be given direct access. The structure of these object identifiers does not permit the extraction of any sensitive information. Two other objects, alarmClearResourceId, and alarmActiveResourceId, are also syntactically object identifiers, but their structure could provide a user with potentially useful information to which he or she might not otherwise be granted access, such as the existence of a particular resource." Whew. Randy From disman-admin@ietf.org Wed Oct 8 15:15: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 PAA04433 for ; Wed, 8 Oct 2003 15:15:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Jm1-0003xJ-Km; Wed, 08 Oct 2003 15:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Jl7-0003sK-70 for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:14:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04267 for ; Wed, 8 Oct 2003 15:13:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Jl5-00033A-00 for disman@ietf.org; Wed, 08 Oct 2003 15:14:03 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7Jl5-000337-00 for disman@ietf.org; Wed, 08 Oct 2003 15:14:03 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7Jl5-0005L2-00 for disman@ietf.org; Wed, 08 Oct 2003 12:14:03 -0700 Message-ID: <000901c38dd0$5e2fa2c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D287F4@zcard0ka.ca.nortel.com> Subject: Re: [Disman] alarmActiveEngineAddress 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: Wed, 8 Oct 2003 12:14:16 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 11:18 AM > Subject: RE: [Disman] alarmActiveEngineAddress ... > No change will be done to address the second observation. The Engine ID > object indicates that it identifies the source of the alarm and this > indicates it is used when that isn't available. ... But that's not what the description says. The sentence "This is used to identify the source of an SNMPv1 trap, since an alarmActiveEngineId cannot be extracted from the SNMPv1 trap PDU." is still wrong. Even if one has an EngineId, one *still* needs an address to get there. Proposed replacement: Delete the sentence. Randy From exim@www1.ietf.org Wed Oct 8 15:15: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 PAA04450 for ; Wed, 8 Oct 2003 15:15:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Jm3-0003z7-Tz for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 15:15:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98JF3X8015311 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 15:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Jm3-0003yp-DJ for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 15:15:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04389 for ; Wed, 8 Oct 2003 15:14:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Jm1-00034G-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:15:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7Jm1-00034D-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:15:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Jm1-0003xJ-Km; Wed, 08 Oct 2003 15:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Jl7-0003sK-70 for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:14:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04267 for ; Wed, 8 Oct 2003 15:13:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Jl5-00033A-00 for disman@ietf.org; Wed, 08 Oct 2003 15:14:03 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7Jl5-000337-00 for disman@ietf.org; Wed, 08 Oct 2003 15:14:03 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7Jl5-0005L2-00 for disman@ietf.org; Wed, 08 Oct 2003 12:14:03 -0700 Message-ID: <000901c38dd0$5e2fa2c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D287F4@zcard0ka.ca.nortel.com> Subject: Re: [Disman] alarmActiveEngineAddress 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: Wed, 8 Oct 2003 12:14:16 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 11:18 AM > Subject: RE: [Disman] alarmActiveEngineAddress ... > No change will be done to address the second observation. The Engine ID > object indicates that it identifies the source of the alarm and this > indicates it is used when that isn't available. ... But that's not what the description says. The sentence "This is used to identify the source of an SNMPv1 trap, since an alarmActiveEngineId cannot be extracted from the SNMPv1 trap PDU." is still wrong. Even if one has an EngineId, one *still* needs an address to get there. Proposed replacement: Delete the sentence. Randy From disman-admin@ietf.org Wed Oct 8 15:24:24 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 PAA05090 for ; Wed, 8 Oct 2003 15:24:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Juj-0004NY-Uu; Wed, 08 Oct 2003 15:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Jtp-0004Ml-3F for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:23:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05058 for ; Wed, 8 Oct 2003 15:22:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Jtn-0003Bi-00 for disman@ietf.org; Wed, 08 Oct 2003 15:23:03 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7Jtn-0003Bd-00 for disman@ietf.org; Wed, 08 Oct 2003 15:23:03 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7Jtn-0004xc-00 for disman@ietf.org; Wed, 08 Oct 2003 12:23:03 -0700 Message-ID: <001001c38dd1$9fdf5200$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D28899@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 8 Oct 2003 12:23:16 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 12:01 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 is closed with no changes to the draft. > > Section 4.1.1 says > > "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." > > Therefore the distinction that Randy is making is a moot point. ... I disagree. The current text effectively says that for each entry in the alarmModelTable there will be zero or one entries in any given specific MIB alarm model table, though one might argue whether the limitations of alarmModelSpecificPointer result in a total limit of 1:(0,1) or 1:(0,n) where n is the number of specific models possible. So my question still stands: Are the numbers in ituAlarmActiveStatsTable for stuff modeled using the ituAlarmTable, or for the whole system? Randy From exim@www1.ietf.org Wed Oct 8 15:24: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 PAA05105 for ; Wed, 8 Oct 2003 15:24:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Jul-0004OL-Rc for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 15:24:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98JO3ox016877 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 15:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Jul-0004O8-Np for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 15:24:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05075 for ; Wed, 8 Oct 2003 15:23:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Juk-0003CM-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:24:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7Juj-0003CJ-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Juj-0004NY-Uu; Wed, 08 Oct 2003 15:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Jtp-0004Ml-3F for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:23:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05058 for ; Wed, 8 Oct 2003 15:22:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Jtn-0003Bi-00 for disman@ietf.org; Wed, 08 Oct 2003 15:23:03 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7Jtn-0003Bd-00 for disman@ietf.org; Wed, 08 Oct 2003 15:23:03 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7Jtn-0004xc-00 for disman@ietf.org; Wed, 08 Oct 2003 12:23:03 -0700 Message-ID: <001001c38dd1$9fdf5200$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D28899@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 8 Oct 2003 12:23:16 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 12:01 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 is closed with no changes to the draft. > > Section 4.1.1 says > > "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." > > Therefore the distinction that Randy is making is a moot point. ... I disagree. The current text effectively says that for each entry in the alarmModelTable there will be zero or one entries in any given specific MIB alarm model table, though one might argue whether the limitations of alarmModelSpecificPointer result in a total limit of 1:(0,1) or 1:(0,n) where n is the number of specific models possible. So my question still stands: Are the numbers in ituAlarmActiveStatsTable for stuff modeled using the ituAlarmTable, or for the whole system? Randy From disman-admin@ietf.org Wed Oct 8 15:35: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 PAA05784 for ; Wed, 8 Oct 2003 15:35:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7K5N-0004kn-8S; Wed, 08 Oct 2003 15:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7K4e-0004kD-DJ for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:34:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05727 for ; Wed, 8 Oct 2003 15:34:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7K4c-0003Ph-00 for disman@ietf.org; Wed, 08 Oct 2003 15:34:14 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7K4c-0003P2-00 for disman@ietf.org; Wed, 08 Oct 2003 15:34:14 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98JXgL07391 for ; Wed, 8 Oct 2003 15:33:43 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 15:33:42 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D85F38@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] IANA considerations in draft-ietf-disman-alarm-mib-1 5.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: Wed, 8 Oct 2003 15:33:42 -0400 Hi The following is the proposed resolution to Randy-66. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 5.2, replace " assigned. Values of IANAProbableCause greater than 1024 may be assigned for causes not covered by existing probable causes." With " assigned. Values of IANAProbableCause greater than 1024 may be assigned on a first come first served basis for causes not covered by existing probable causes." As requiring an RFC to explain what 'shelfOnFire" means is just a make work project. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 02, 2003 6:42 PM To: Disman (E-mail) Subject: [Disman] IANA considerations in 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 > ... > 66) 5.2: we will probably need to give IANA more guidance on how additions > should be approved. We agreed that we didn't want an immortal WG, but > we do need to tell them what kind of review, if any, is needed before > a addition is made. ... Though this is marked "changed", I can't find a statement about what kind of review is needed for additions. I think RFC 2434 section 4 is pretty clear that this is needed. I propose the "specification required" level of review. Other thoughts? Randy From exim@www1.ietf.org Wed Oct 8 15:35: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 PAA05799 for ; Wed, 8 Oct 2003 15:35:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7K5R-0004mu-DL for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 15:35:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98JZ5MQ018401 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 15:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7K5R-0004mi-9M for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 15:35:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05764 for ; Wed, 8 Oct 2003 15:34:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7K5P-0003QL-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:35:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7K5P-0003QI-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:35:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7K5N-0004kn-8S; Wed, 08 Oct 2003 15:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7K4e-0004kD-DJ for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:34:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05727 for ; Wed, 8 Oct 2003 15:34:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7K4c-0003Ph-00 for disman@ietf.org; Wed, 08 Oct 2003 15:34:14 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7K4c-0003P2-00 for disman@ietf.org; Wed, 08 Oct 2003 15:34:14 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98JXgL07391 for ; Wed, 8 Oct 2003 15:33:43 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 15:33:42 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D85F38@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] IANA considerations in draft-ietf-disman-alarm-mib-1 5.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: Wed, 8 Oct 2003 15:33:42 -0400 Hi The following is the proposed resolution to Randy-66. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 5.2, replace " assigned. Values of IANAProbableCause greater than 1024 may be assigned for causes not covered by existing probable causes." With " assigned. Values of IANAProbableCause greater than 1024 may be assigned on a first come first served basis for causes not covered by existing probable causes." As requiring an RFC to explain what 'shelfOnFire" means is just a make work project. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 02, 2003 6:42 PM To: Disman (E-mail) Subject: [Disman] IANA considerations in 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 > ... > 66) 5.2: we will probably need to give IANA more guidance on how additions > should be approved. We agreed that we didn't want an immortal WG, but > we do need to tell them what kind of review, if any, is needed before > a addition is made. ... Though this is marked "changed", I can't find a statement about what kind of review is needed for additions. I think RFC 2434 section 4 is pretty clear that this is needed. I propose the "specification required" level of review. Other thoughts? Randy From disman-admin@ietf.org Wed Oct 8 15:48: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 PAA06223 for ; Wed, 8 Oct 2003 15:48:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KHx-0005i0-7v; Wed, 08 Oct 2003 15:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KHC-0005hA-Ny for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:47:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06193 for ; Wed, 8 Oct 2003 15:47:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KHB-0003ZZ-00 for disman@ietf.org; Wed, 08 Oct 2003 15:47:13 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7KHA-0003ZV-00 for disman@ietf.org; Wed, 08 Oct 2003 15:47:12 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7KHA-0006I8-00 for disman@ietf.org; Wed, 08 Oct 2003 12:47:12 -0700 Message-ID: <002301c38dd4$ffa20fe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D85F38@zcard0ka.ca.nortel.com> Subject: Re: [Disman] IANA considerations in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 8 Oct 2003 12:47:25 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 12:33 PM > Subject: RE: [Disman] IANA considerations in draft-ietf-disman-alarm-mib-15.txt ... > As requiring an RFC to explain what 'shelfOnFire" means is just a make work > project. .. It sounds like there's a misconception here. "Specification required" does NOT mean an RFC is required. RFC 2434 says: | Specification Required - Values and their meaning must be | documented in an RFC or other permanent and readily available | reference, in sufficient detail so that interoperability | between independent implementations is possible. This seems to me to be exactly what we'd want to make it easy enough to add values when needed, but with enough of a bar to prevent ad hoc and willy-nilly proliferation. Randy From exim@www1.ietf.org Wed Oct 8 15:48:24 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 PAA06238 for ; Wed, 8 Oct 2003 15:48:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KHz-0005iv-51 for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 15:48:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Jm3jX021995 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 15:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KHz-0005ig-1f for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 15:48:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06214 for ; Wed, 8 Oct 2003 15:47:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KHx-0003a7-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:48:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7KHx-0003a4-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:48:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KHx-0005i0-7v; Wed, 08 Oct 2003 15:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KHC-0005hA-Ny for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:47:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06193 for ; Wed, 8 Oct 2003 15:47:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KHB-0003ZZ-00 for disman@ietf.org; Wed, 08 Oct 2003 15:47:13 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7KHA-0003ZV-00 for disman@ietf.org; Wed, 08 Oct 2003 15:47:12 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7KHA-0006I8-00 for disman@ietf.org; Wed, 08 Oct 2003 12:47:12 -0700 Message-ID: <002301c38dd4$ffa20fe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D85F38@zcard0ka.ca.nortel.com> Subject: Re: [Disman] IANA considerations in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 8 Oct 2003 12:47:25 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 12:33 PM > Subject: RE: [Disman] IANA considerations in draft-ietf-disman-alarm-mib-15.txt ... > As requiring an RFC to explain what 'shelfOnFire" means is just a make work > project. .. It sounds like there's a misconception here. "Specification required" does NOT mean an RFC is required. RFC 2434 says: | Specification Required - Values and their meaning must be | documented in an RFC or other permanent and readily available | reference, in sufficient detail so that interoperability | between independent implementations is possible. This seems to me to be exactly what we'd want to make it easy enough to add values when needed, but with enough of a bar to prevent ad hoc and willy-nilly proliferation. Randy From disman-admin@ietf.org Wed Oct 8 15:50: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 PAA06344 for ; Wed, 8 Oct 2003 15:50:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KJu-0005nD-1L; Wed, 08 Oct 2003 15:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KIu-0005lk-Tx for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:49:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06264 for ; Wed, 8 Oct 2003 15:48:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KIo-0003aU-00 for disman@ietf.org; Wed, 08 Oct 2003 15:48:54 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7KIn-0003aE-00 for disman@ietf.org; Wed, 08 Oct 2003 15:48:53 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98JmLL09437 for ; Wed, 8 Oct 2003 15:48:22 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 15:48:21 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D85F70@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn 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: Wed, 8 Oct 2003 15:48:20 -0400 Hi The following is the proposed resolution to Randy-75-2. Assuming no objection, this item will is closed with no changes to the draft. 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. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 02, 2003 6:56 PM To: Disman (E-mail) Subject: [Disman] Security considerations in draft-ietf-disman-alarm-mib-15.txt Hi - WG chair hat on: > 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 ... > 75-2) This section should also mention throttling / DoS attacks based > on notification generation. > > Sharon->Neither of the examples given in the MIB Review Guidelines do ... Given the IESG's comments on the ARC MIB, I believe we need to reconsider this comment. Randy Presuhn, disman WG chair From exim@www1.ietf.org Wed Oct 8 15:50: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 PAA06359 for ; Wed, 8 Oct 2003 15:50:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KJw-0005qg-10 for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 15:50:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Jo3Kk022446 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 15:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KJv-0005oz-JF for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 15:50:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06319 for ; Wed, 8 Oct 2003 15:49:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KJt-0003bK-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:50:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7KJt-0003bH-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:50:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KJu-0005nD-1L; Wed, 08 Oct 2003 15:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KIu-0005lk-Tx for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:49:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06264 for ; Wed, 8 Oct 2003 15:48:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KIo-0003aU-00 for disman@ietf.org; Wed, 08 Oct 2003 15:48:54 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7KIn-0003aE-00 for disman@ietf.org; Wed, 08 Oct 2003 15:48:53 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98JmLL09437 for ; Wed, 8 Oct 2003 15:48:22 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 15:48:21 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D85F70@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn 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: Wed, 8 Oct 2003 15:48:20 -0400 Hi The following is the proposed resolution to Randy-75-2. Assuming no objection, this item will is closed with no changes to the draft. 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. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 02, 2003 6:56 PM To: Disman (E-mail) Subject: [Disman] Security considerations in draft-ietf-disman-alarm-mib-15.txt Hi - WG chair hat on: > 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 ... > 75-2) This section should also mention throttling / DoS attacks based > on notification generation. > > Sharon->Neither of the examples given in the MIB Review Guidelines do ... Given the IESG's comments on the ARC MIB, I believe we need to reconsider this comment. Randy Presuhn, disman WG chair From disman-admin@ietf.org Wed Oct 8 15:52: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 PAA06445 for ; Wed, 8 Oct 2003 15:52:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KLo-0005tg-Dp; Wed, 08 Oct 2003 15:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KKy-0005sW-AO for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:51:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06385 for ; Wed, 8 Oct 2003 15:50:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KKw-0003ce-00 for disman@ietf.org; Wed, 08 Oct 2003 15:51:06 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A7KKw-0003cN-00 for disman@ietf.org; Wed, 08 Oct 2003 15:51:06 -0400 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 h98JoYB21614 for ; Wed, 8 Oct 2003 15:50:35 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 15:50:34 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D85F79@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] IANA considerations in draft-ietf-disman-alarm-mib-1 5.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: Wed, 8 Oct 2003 15:50:34 -0400 Hi RFC2434 says " Specification Required - Values and their meaning must be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible. " This is overkill. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 3:47 PM To: Disman (E-mail) Subject: Re: [Disman] IANA 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:33 PM > Subject: RE: [Disman] IANA considerations in > draft-ietf-disman-alarm-mib-15.txt ... > As requiring an RFC to explain what 'shelfOnFire" means is just a make > work project. .. It sounds like there's a misconception here. "Specification required" does NOT mean an RFC is required. RFC 2434 says: | Specification Required - Values and their meaning must be | documented in an RFC or other permanent and readily available | reference, in sufficient detail so that interoperability | between independent implementations is possible. This seems to me to be exactly what we'd want to make it easy enough to add values when needed, but with enough of a bar to prevent ad hoc and willy-nilly proliferation. Randy From exim@www1.ietf.org Wed Oct 8 15:52:22 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 PAA06460 for ; Wed, 8 Oct 2003 15:52:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KLp-0005wb-IA for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 15:52:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Jq1Jv022843 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 15:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KLp-0005wM-EP for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 15:52:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06421 for ; Wed, 8 Oct 2003 15:51:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KLn-0003dE-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:51:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7KLn-0003dB-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:51:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KLo-0005tg-Dp; Wed, 08 Oct 2003 15:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KKy-0005sW-AO for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:51:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06385 for ; Wed, 8 Oct 2003 15:50:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KKw-0003ce-00 for disman@ietf.org; Wed, 08 Oct 2003 15:51:06 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A7KKw-0003cN-00 for disman@ietf.org; Wed, 08 Oct 2003 15:51:06 -0400 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 h98JoYB21614 for ; Wed, 8 Oct 2003 15:50:35 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 15:50:34 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D85F79@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] IANA considerations in draft-ietf-disman-alarm-mib-1 5.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: Wed, 8 Oct 2003 15:50:34 -0400 Hi RFC2434 says " Specification Required - Values and their meaning must be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible. " This is overkill. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 3:47 PM To: Disman (E-mail) Subject: Re: [Disman] IANA 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:33 PM > Subject: RE: [Disman] IANA considerations in > draft-ietf-disman-alarm-mib-15.txt ... > As requiring an RFC to explain what 'shelfOnFire" means is just a make > work project. .. It sounds like there's a misconception here. "Specification required" does NOT mean an RFC is required. RFC 2434 says: | Specification Required - Values and their meaning must be | documented in an RFC or other permanent and readily available | reference, in sufficient detail so that interoperability | between independent implementations is possible. This seems to me to be exactly what we'd want to make it easy enough to add values when needed, but with enough of a bar to prevent ad hoc and willy-nilly proliferation. Randy From disman-admin@ietf.org Wed Oct 8 15:58:29 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 PAA06617 for ; Wed, 8 Oct 2003 15:58:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KRd-0006FX-EU; Wed, 08 Oct 2003 15:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KRR-0006F5-5y for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:57:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06591 for ; Wed, 8 Oct 2003 15:57:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KRP-0003h5-00 for disman@ietf.org; Wed, 08 Oct 2003 15:57:47 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7KRP-0003h2-00 for disman@ietf.org; Wed, 08 Oct 2003 15:57:47 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7KRP-0000dS-00 for disman@ietf.org; Wed, 08 Oct 2003 12:57:47 -0700 Message-ID: <003001c38dd6$7a302840$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D85F70@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Security considerations in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 8 Oct 2003 12:58:00 -0700 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 Oct 8 15:58: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 PAA06644 for ; Wed, 8 Oct 2003 15:58:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KRl-0006H7-24 for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 15:58:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Jw8LT024109 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 15:58:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KRk-0006Gl-Th for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 15:58:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06610 for ; Wed, 8 Oct 2003 15:57:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KRj-0003hx-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:58:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7KRi-0003hr-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:58:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KRd-0006FX-EU; Wed, 08 Oct 2003 15:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KRR-0006F5-5y for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:57:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06591 for ; Wed, 8 Oct 2003 15:57:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KRP-0003h5-00 for disman@ietf.org; Wed, 08 Oct 2003 15:57:47 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7KRP-0003h2-00 for disman@ietf.org; Wed, 08 Oct 2003 15:57:47 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7KRP-0000dS-00 for disman@ietf.org; Wed, 08 Oct 2003 12:57:47 -0700 Message-ID: <003001c38dd6$7a302840$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D85F70@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Security considerations in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 8 Oct 2003 12:58:00 -0700 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 Oct 8 16: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 QAA06747 for ; Wed, 8 Oct 2003 16:00:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KTb-0006NP-JJ; Wed, 08 Oct 2003 16:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KSw-0006MC-Cm for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:59:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06684 for ; Wed, 8 Oct 2003 15:59:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KSt-0003iv-00 for disman@ietf.org; Wed, 08 Oct 2003 15:59:19 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7KSt-0003is-00 for disman@ietf.org; Wed, 08 Oct 2003 15:59:19 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7KSt-0003FG-00 for disman@ietf.org; Wed, 08 Oct 2003 12:59:19 -0700 Message-ID: <003701c38dd6$b12f7120$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D85F79@zcard0ka.ca.nortel.com> Subject: Re: [Disman] IANA considerations in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 8 Oct 2003 12:59:32 -0700 Hi - WG chair asks: other opinions to break this deadlock? Randy > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 12:50 PM > Subject: RE: [Disman] IANA considerations in draft-ietf-disman-alarm-mib-15.txt > > Hi > > RFC2434 says > > " > Specification Required - Values and their meaning must be > documented in an RFC or other permanent and readily available > reference, in sufficient detail so that interoperability > between independent implementations is possible. > " > > This is overkill. > > Sharon > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Wednesday, October 08, 2003 3:47 PM > To: Disman (E-mail) > Subject: Re: [Disman] IANA 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:33 PM > > Subject: RE: [Disman] IANA considerations in > > draft-ietf-disman-alarm-mib-15.txt > ... > > As requiring an RFC to explain what 'shelfOnFire" means is just a make > > work project. > .. > > It sounds like there's a misconception here. > "Specification required" does NOT mean an RFC is required. > RFC 2434 says: > > | Specification Required - Values and their meaning must be > | documented in an RFC or other permanent and readily available > | reference, in sufficient detail so that interoperability > | between independent implementations is possible. > > This seems to me to be exactly what we'd want to make it easy enough to add > values when needed, but with enough of a bar to prevent ad hoc and > willy-nilly proliferation. > > Randy > > > From exim@www1.ietf.org Wed Oct 8 16:00:28 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 QAA06767 for ; Wed, 8 Oct 2003 16:00:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KTf-0006QC-8c for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 16:00:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98K077Y024670 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 16:00:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KTd-0006PX-Aj for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 16:00:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06718 for ; Wed, 8 Oct 2003 15:59:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KTb-0003k0-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 16:00:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7KTb-0003jx-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 16:00:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KTb-0006NP-JJ; Wed, 08 Oct 2003 16:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KSw-0006MC-Cm for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:59:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06684 for ; Wed, 8 Oct 2003 15:59:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KSt-0003iv-00 for disman@ietf.org; Wed, 08 Oct 2003 15:59:19 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7KSt-0003is-00 for disman@ietf.org; Wed, 08 Oct 2003 15:59:19 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7KSt-0003FG-00 for disman@ietf.org; Wed, 08 Oct 2003 12:59:19 -0700 Message-ID: <003701c38dd6$b12f7120$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D85F79@zcard0ka.ca.nortel.com> Subject: Re: [Disman] IANA considerations in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 8 Oct 2003 12:59:32 -0700 Hi - WG chair asks: other opinions to break this deadlock? Randy > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 12:50 PM > Subject: RE: [Disman] IANA considerations in draft-ietf-disman-alarm-mib-15.txt > > Hi > > RFC2434 says > > " > Specification Required - Values and their meaning must be > documented in an RFC or other permanent and readily available > reference, in sufficient detail so that interoperability > between independent implementations is possible. > " > > This is overkill. > > Sharon > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Wednesday, October 08, 2003 3:47 PM > To: Disman (E-mail) > Subject: Re: [Disman] IANA 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:33 PM > > Subject: RE: [Disman] IANA considerations in > > draft-ietf-disman-alarm-mib-15.txt > ... > > As requiring an RFC to explain what 'shelfOnFire" means is just a make > > work project. > .. > > It sounds like there's a misconception here. > "Specification required" does NOT mean an RFC is required. > RFC 2434 says: > > | Specification Required - Values and their meaning must be > | documented in an RFC or other permanent and readily available > | reference, in sufficient detail so that interoperability > | between independent implementations is possible. > > This seems to me to be exactly what we'd want to make it easy enough to add > values when needed, but with enough of a bar to prevent ad hoc and > willy-nilly proliferation. > > Randy > > > From disman-admin@ietf.org Wed Oct 8 16:10: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 QAA07049 for ; Wed, 8 Oct 2003 16:10:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KdG-00075t-GF; Wed, 08 Oct 2003 16:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Kd9-00075R-6X for disman@optimus.ietf.org; Wed, 08 Oct 2003 16:09:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07032 for ; Wed, 8 Oct 2003 16:09:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Kd7-0003oO-00 for disman@ietf.org; Wed, 08 Oct 2003 16:09:53 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A7Kd6-0003oH-00 for disman@ietf.org; Wed, 08 Oct 2003 16:09:52 -0400 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 h98K99B29657 for ; Wed, 8 Oct 2003 16:09:10 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 16:09:09 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D85FB2@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn 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: Wed, 8 Oct 2003 16:09:09 -0400 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 Oct 8 16:10:28 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 QAA07064 for ; Wed, 8 Oct 2003 16:10:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KdK-00077Y-JP for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 16:10:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98KA681027366 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 16:10:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KdK-00077J-8q for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 16:10:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07040 for ; Wed, 8 Oct 2003 16:09:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KdI-0003oc-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 16:10:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7KdI-0003oZ-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 16:10:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KdG-00075t-GF; Wed, 08 Oct 2003 16:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Kd9-00075R-6X for disman@optimus.ietf.org; Wed, 08 Oct 2003 16:09:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07032 for ; Wed, 8 Oct 2003 16:09:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Kd7-0003oO-00 for disman@ietf.org; Wed, 08 Oct 2003 16:09:53 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A7Kd6-0003oH-00 for disman@ietf.org; Wed, 08 Oct 2003 16:09:52 -0400 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 h98K99B29657 for ; Wed, 8 Oct 2003 16:09:10 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 16:09:09 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D85FB2@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn 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: Wed, 8 Oct 2003 16:09:09 -0400 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 Oct 8 16:21:22 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 QAA07501 for ; Wed, 8 Oct 2003 16:21:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Knt-0007am-Fu; Wed, 08 Oct 2003 16:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KnQ-0007Zk-8w for disman@optimus.ietf.org; Wed, 08 Oct 2003 16:20:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07485 for ; Wed, 8 Oct 2003 16:20:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KnO-0003vL-00 for disman@ietf.org; Wed, 08 Oct 2003 16:20:30 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7KnN-0003uy-00 for disman@ietf.org; Wed, 08 Oct 2003 16:20:29 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98KJwL21939 for ; Wed, 8 Oct 2003 16:19:58 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 16:19:58 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D85FD6@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: Wed, 8 Oct 2003 16:19:57 -0400 Hi I've just realized this is a bad example. The existing throttling text ensures this doesn't happen. 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 Oct 8 16:21: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 QAA07516 for ; Wed, 8 Oct 2003 16:21:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Knu-0007bY-Ss for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 16:21:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98KL2fe029226 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 16:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Knu-0007bJ-OR for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 16:21:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07491 for ; Wed, 8 Oct 2003 16:20:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Kns-0003vU-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 16:21:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7Kns-0003vR-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 16:21:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Knt-0007am-Fu; Wed, 08 Oct 2003 16:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KnQ-0007Zk-8w for disman@optimus.ietf.org; Wed, 08 Oct 2003 16:20:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07485 for ; Wed, 8 Oct 2003 16:20:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KnO-0003vL-00 for disman@ietf.org; Wed, 08 Oct 2003 16:20:30 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7KnN-0003uy-00 for disman@ietf.org; Wed, 08 Oct 2003 16:20:29 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98KJwL21939 for ; Wed, 8 Oct 2003 16:19:58 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 16:19:58 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D85FD6@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: Wed, 8 Oct 2003 16:19:57 -0400 Hi I've just realized this is a bad example. The existing throttling text ensures this doesn't happen. 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 Oct 8 16:27:22 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 QAA07745 for ; Wed, 8 Oct 2003 16:27:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Ktg-0007t1-Vq; Wed, 08 Oct 2003 16:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Kta-0007sd-4x for disman@optimus.ietf.org; Wed, 08 Oct 2003 16:26:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07711 for ; Wed, 8 Oct 2003 16:26:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KtY-0003yF-00 for disman@ietf.org; Wed, 08 Oct 2003 16:26:52 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A7KtX-0003yB-00 for disman@ietf.org; Wed, 08 Oct 2003 16:26:51 -0400 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 h98KQKB01433 for ; Wed, 8 Oct 2003 16:26:20 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 16:26:20 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D85FF1@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] zero-based counters in draft-ietf-disman-alarm-mib-1 5.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: Wed, 8 Oct 2003 16:26:18 -0400 Hi Do we really feel that the current description and data type will result in non-interoperable implementations? Other than the fact there was a neater data type that we could have used instead, I don't really see a problem here. I think the text is sufficient for people to know to start the thing at 0 if nothing has happened. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 02, 2003 10:54 PM To: Disman (E-mail) Subject: [Disman] zero-based counters in 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 ... > 62) alarmActiveStatsActives, the SYNTAX says this is a Counter32, > but the DESCRIPTION sure makes it sound like it's supposed to > be zero-based. > > 71) ituAlarmActiveStatsIndeterminates, > ituAlarmActiveStatsCriticals, > ituAlarmActiveStatsMajors, > ituAlarmActiveStatsMinors, and > ituAlarmActiveStatsWarnings are all Counter32, but their > DESCRIPTIONs sound like they're assumed to be zero-based. > > Sharon-> Counter32 can have a value of 0. ... Let me put it another way: if none of these events have occured since system restart, what will the value of these objects be? a) zero, since the descriptions say they are counts "since system restart" if this is the case, they should use the ZeroBasedCounter32 TC b) not predictable, given the defnition of Counter32 in RFC 2578 clause 7.1.6 if this is the case, then the "since system restart" words are misleading Randy (technical contributor) From exim@www1.ietf.org Wed Oct 8 16:27: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 QAA07760 for ; Wed, 8 Oct 2003 16:27:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Kti-0007tq-Iv for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 16:27:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98KR2K4030360 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 16:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Kti-0007tb-EK for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 16:27:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07722 for ; Wed, 8 Oct 2003 16:26:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Ktg-0003yT-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 16:27:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7Ktg-0003yQ-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 16:27:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Ktg-0007t1-Vq; Wed, 08 Oct 2003 16:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Kta-0007sd-4x for disman@optimus.ietf.org; Wed, 08 Oct 2003 16:26:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07711 for ; Wed, 8 Oct 2003 16:26:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KtY-0003yF-00 for disman@ietf.org; Wed, 08 Oct 2003 16:26:52 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A7KtX-0003yB-00 for disman@ietf.org; Wed, 08 Oct 2003 16:26:51 -0400 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 h98KQKB01433 for ; Wed, 8 Oct 2003 16:26:20 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 16:26:20 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D85FF1@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] zero-based counters in draft-ietf-disman-alarm-mib-1 5.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: Wed, 8 Oct 2003 16:26:18 -0400 Hi Do we really feel that the current description and data type will result in non-interoperable implementations? Other than the fact there was a neater data type that we could have used instead, I don't really see a problem here. I think the text is sufficient for people to know to start the thing at 0 if nothing has happened. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 02, 2003 10:54 PM To: Disman (E-mail) Subject: [Disman] zero-based counters in 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 ... > 62) alarmActiveStatsActives, the SYNTAX says this is a Counter32, > but the DESCRIPTION sure makes it sound like it's supposed to > be zero-based. > > 71) ituAlarmActiveStatsIndeterminates, > ituAlarmActiveStatsCriticals, > ituAlarmActiveStatsMajors, > ituAlarmActiveStatsMinors, and > ituAlarmActiveStatsWarnings are all Counter32, but their > DESCRIPTIONs sound like they're assumed to be zero-based. > > Sharon-> Counter32 can have a value of 0. ... Let me put it another way: if none of these events have occured since system restart, what will the value of these objects be? a) zero, since the descriptions say they are counts "since system restart" if this is the case, they should use the ZeroBasedCounter32 TC b) not predictable, given the defnition of Counter32 in RFC 2578 clause 7.1.6 if this is the case, then the "since system restart" words are misleading Randy (technical contributor) From disman-admin@ietf.org Wed Oct 8 16:35: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 QAA08016 for ; Wed, 8 Oct 2003 16:35:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7L1S-00087l-09; Wed, 08 Oct 2003 16:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7L0s-00087P-TH for disman@optimus.ietf.org; Wed, 08 Oct 2003 16:34:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07965 for ; Wed, 8 Oct 2003 16:34:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7L0q-00043R-00 for disman@ietf.org; Wed, 08 Oct 2003 16:34:24 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7L0q-00043O-00 for disman@ietf.org; Wed, 08 Oct 2003 16:34:24 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7L0o-00010O-00 for disman@ietf.org; Wed, 08 Oct 2003 13:34:22 -0700 Message-ID: <004801c38ddb$96cbd1c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D85FB2@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Security considerations in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 8 Oct 2003 13:34:35 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 1:09 PM > Subject: RE: [Disman] Security considerations in draft-ietf-disman-alarm-mib-15.txt ... > 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? ... That's getting into the spirit. Particularly if the manager is a bad guy and has those 323432 notifications sent to some other system as (part of) a DDoS attack. A really obnoxious one would be to set up a two-entry alarm model to form a feedback loop: seeing any alarmActiveState triggers an alarmClearState, which in turn triggers an alarmActiveState. As soon as some other alarm (innocently) becomes active, and endless cascade starts. It can't be turned off because of the way alarmModelRowStatus works. Because it's an oscillation, the throttle won't slow it down. Resetting the box wouldn't stop it; the only hope would be to nip it in the bud using RFC 3413. Meanwhile, whatever manager(s) were identified as targets would be drowning in notifications. That's why these objects are sensitive and should be protected by an appropriate security policy. Randy From exim@www1.ietf.org Wed Oct 8 16:35: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 QAA08031 for ; Wed, 8 Oct 2003 16:35:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7L1U-00088X-7B for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 16:35:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98KZ4MV031271 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 16:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7L1T-00088I-Vn for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 16:35:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07982 for ; Wed, 8 Oct 2003 16:34:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7L1R-00043e-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 16:35:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7L1R-00043b-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 16:35:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7L1S-00087l-09; Wed, 08 Oct 2003 16:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7L0s-00087P-TH for disman@optimus.ietf.org; Wed, 08 Oct 2003 16:34:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07965 for ; Wed, 8 Oct 2003 16:34:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7L0q-00043R-00 for disman@ietf.org; Wed, 08 Oct 2003 16:34:24 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7L0q-00043O-00 for disman@ietf.org; Wed, 08 Oct 2003 16:34:24 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7L0o-00010O-00 for disman@ietf.org; Wed, 08 Oct 2003 13:34:22 -0700 Message-ID: <004801c38ddb$96cbd1c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D85FB2@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Security considerations in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 8 Oct 2003 13:34:35 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 1:09 PM > Subject: RE: [Disman] Security considerations in draft-ietf-disman-alarm-mib-15.txt ... > 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? ... That's getting into the spirit. Particularly if the manager is a bad guy and has those 323432 notifications sent to some other system as (part of) a DDoS attack. A really obnoxious one would be to set up a two-entry alarm model to form a feedback loop: seeing any alarmActiveState triggers an alarmClearState, which in turn triggers an alarmActiveState. As soon as some other alarm (innocently) becomes active, and endless cascade starts. It can't be turned off because of the way alarmModelRowStatus works. Because it's an oscillation, the throttle won't slow it down. Resetting the box wouldn't stop it; the only hope would be to nip it in the bud using RFC 3413. Meanwhile, whatever manager(s) were identified as targets would be drowning in notifications. That's why these objects are sensitive and should be protected by an appropriate security policy. Randy From disman-admin@ietf.org Wed Oct 8 16:38: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 QAA08143 for ; Wed, 8 Oct 2003 16:38:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7L4M-0008Ti-0R; Wed, 08 Oct 2003 16:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7L49-0008QD-TM for disman@optimus.ietf.org; Wed, 08 Oct 2003 16:37:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08116 for ; Wed, 8 Oct 2003 16:37:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7L47-00045Z-00 for disman@ietf.org; Wed, 08 Oct 2003 16:37:47 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7L47-00045W-00 for disman@ietf.org; Wed, 08 Oct 2003 16:37:47 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7L46-0006qF-00 for disman@ietf.org; Wed, 08 Oct 2003 13:37:46 -0700 Message-ID: <005101c38ddc$1083cae0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D85FD6@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Security considerations in draft-ietf-disman-alarm-m ib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 8 Oct 2003 13:38:00 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Wednesday, October 08, 2003 1:19 PM > Subject: RE: [Disman] Security considerations in draft-ietf-disman-alarm-m ib-15.txt ... > I've just realized this is a bad example. The existing throttling text > ensures this doesn't happen. ... Actually,your example is fine because the existing throttle text won't stop it. The text requires least a two-second gap between traps of this type against the same alarmActiveModelPointer and alarmActiveResourceId They'd have different alarmActiveModelPointer values, and would consequently get right past the throttle. Randy From exim@www1.ietf.org Wed Oct 8 16:38:24 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 QAA08166 for ; Wed, 8 Oct 2003 16:38:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7L4O-00005Y-4y for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 16:38:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Kc3jK000326 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 16:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7L4N-000057-Hj for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 16:38:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08129 for ; Wed, 8 Oct 2003 16:37:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7L4L-00045w-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 16:38:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7L4L-00045t-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 16:38:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7L4M-0008Ti-0R; Wed, 08 Oct 2003 16:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7L49-0008QD-TM for disman@optimus.ietf.org; Wed, 08 Oct 2003 16:37:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08116 for ; Wed, 8 Oct 2003 16:37:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7L47-00045Z-00 for disman@ietf.org; Wed, 08 Oct 2003 16:37:47 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7L47-00045W-00 for disman@ietf.org; Wed, 08 Oct 2003 16:37:47 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7L46-0006qF-00 for disman@ietf.org; Wed, 08 Oct 2003 13:37:46 -0700 Message-ID: <005101c38ddc$1083cae0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D85FD6@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Security considerations in draft-ietf-disman-alarm-m ib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 8 Oct 2003 13:38:00 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Wednesday, October 08, 2003 1:19 PM > Subject: RE: [Disman] Security considerations in draft-ietf-disman-alarm-m ib-15.txt ... > I've just realized this is a bad example. The existing throttling text > ensures this doesn't happen. ... Actually,your example is fine because the existing throttle text won't stop it. The text requires least a two-second gap between traps of this type against the same alarmActiveModelPointer and alarmActiveResourceId They'd have different alarmActiveModelPointer values, and would consequently get right past the throttle. Randy From disman-admin@ietf.org Wed Oct 8 16:45:45 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 PAA06618 for ; Wed, 8 Oct 2003 15:58:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KRd-0006Ff-O2; Wed, 08 Oct 2003 15:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KRW-0006FB-5c for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:57:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06594 for ; Wed, 8 Oct 2003 15:57:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KRU-0003hA-00 for disman@ietf.org; Wed, 08 Oct 2003 15:57:52 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7KRT-0003gc-00 for disman@ietf.org; Wed, 08 Oct 2003 15:57:52 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98JvKL10854 for ; Wed, 8 Oct 2003 15:57:21 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 15:57:20 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D85F96@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] ituAlarmServiceUserGroup etc. 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: Wed, 8 Oct 2003 15:57:19 -0400 Hi The following is the proposed resolution to Randy-70 & Randy-72. Assuming no objection, this item will is closed with no changes to the draft. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 02, 2003 7:06 PM To: Disman (E-mail) Subject: [Disman] ituAlarmServiceUserGroup etc. in 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 ... > 70) ituAlarmActiveDetector, ituAlarmActiveServiceProvider, and > ituAlarmActiveServiceUser need better DESCRIPTIONs. I think > it needs to be more explicit that their values are the names > of the object instances corresponding to these resources. > > 72) The DESCRIPTION of ituAlarmServiceUserGroup isn't helpful. > > Sharon->These are the descriptions used in the ITU. It would be a new > Sharon->design item to provide 'improved' descriptions. ... If the ITU definitions really are that vacuous, I guess we're stuck with them. The repeated "This group is optional" DESCRIPTIONs in ituAlarmCompliance don't make me feel any better, but if no one else is bothered by this, I'm willing to let it go and hope the IESG feels the same way. Randy, as disman WG chair. From exim@www1.ietf.org Wed Oct 8 16:45:45 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 PAA06645 for ; Wed, 8 Oct 2003 15:58:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KRl-0006HG-41 for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 15:58:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Jw98e024123 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 15:58:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KRk-0006Gp-VB for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 15:58:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06609 for ; Wed, 8 Oct 2003 15:57:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KRj-0003i0-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:58:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7KRi-0003hu-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 15:58:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KRd-0006Ff-O2; Wed, 08 Oct 2003 15:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7KRW-0006FB-5c for disman@optimus.ietf.org; Wed, 08 Oct 2003 15:57:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06594 for ; Wed, 8 Oct 2003 15:57:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7KRU-0003hA-00 for disman@ietf.org; Wed, 08 Oct 2003 15:57:52 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7KRT-0003gc-00 for disman@ietf.org; Wed, 08 Oct 2003 15:57:52 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98JvKL10854 for ; Wed, 8 Oct 2003 15:57:21 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 15:57:20 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D85F96@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Cc: Randy Presuhn Subject: RE: [Disman] ituAlarmServiceUserGroup etc. 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: Wed, 8 Oct 2003 15:57:19 -0400 Hi The following is the proposed resolution to Randy-70 & Randy-72. Assuming no objection, this item will is closed with no changes to the draft. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 02, 2003 7:06 PM To: Disman (E-mail) Subject: [Disman] ituAlarmServiceUserGroup etc. in 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 ... > 70) ituAlarmActiveDetector, ituAlarmActiveServiceProvider, and > ituAlarmActiveServiceUser need better DESCRIPTIONs. I think > it needs to be more explicit that their values are the names > of the object instances corresponding to these resources. > > 72) The DESCRIPTION of ituAlarmServiceUserGroup isn't helpful. > > Sharon->These are the descriptions used in the ITU. It would be a new > Sharon->design item to provide 'improved' descriptions. ... If the ITU definitions really are that vacuous, I guess we're stuck with them. The repeated "This group is optional" DESCRIPTIONs in ituAlarmCompliance don't make me feel any better, but if no one else is bothered by this, I'm willing to let it go and hope the IESG feels the same way. Randy, as disman WG chair. From disman-admin@ietf.org Wed Oct 8 16:46:22 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 QAA08435 for ; Wed, 8 Oct 2003 16:46:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LC4-0000go-R3; Wed, 08 Oct 2003 16:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LBw-0000gW-4G for disman@optimus.ietf.org; Wed, 08 Oct 2003 16:45:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08382 for ; Wed, 8 Oct 2003 16:45:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7LBt-0004BJ-00 for disman@ietf.org; Wed, 08 Oct 2003 16:45:49 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7LBt-0004BE-00 for disman@ietf.org; Wed, 08 Oct 2003 16:45:49 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98KjHL24875 for ; Wed, 8 Oct 2003 16:45:18 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 16:45:15 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D86038@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] unfixed typo 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: Wed, 8 Oct 2003 16:45:14 -0400 hi The following is the proposed resolution to Randy-11. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 3.1, replace " Notification Unsolicited transmissions of management information." With " Notification Unsolicited transmission of management information." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 03, 2003 12:42 AM To: Disman (E-mail) Subject: [Disman] unfixed typo in alarm-mib-15 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 ... > 11) Page 4: "transmissions of management" -> > "transmission of management" (I personally think that > defining "notification" in terms of transmission is a > mistake, but it's too late to re-hash that discussion.) ... The typo "transmissions" -> "transmission" still needs to be fixed. Randy From exim@www1.ietf.org Wed Oct 8 16:46:24 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 QAA08450 for ; Wed, 8 Oct 2003 16:46:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LC7-0000iQ-1I for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 16:46:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Kk3Hv002744 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 16:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LC6-0000iB-Sz for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 16:46:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08421 for ; Wed, 8 Oct 2003 16:45:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7LC4-0004BX-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 16:46:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7LC4-0004BU-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 16:46:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LC4-0000go-R3; Wed, 08 Oct 2003 16:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LBw-0000gW-4G for disman@optimus.ietf.org; Wed, 08 Oct 2003 16:45:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08382 for ; Wed, 8 Oct 2003 16:45:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7LBt-0004BJ-00 for disman@ietf.org; Wed, 08 Oct 2003 16:45:49 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7LBt-0004BE-00 for disman@ietf.org; Wed, 08 Oct 2003 16:45:49 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98KjHL24875 for ; Wed, 8 Oct 2003 16:45:18 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 16:45:15 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D86038@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] unfixed typo 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: Wed, 8 Oct 2003 16:45:14 -0400 hi The following is the proposed resolution to Randy-11. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 3.1, replace " Notification Unsolicited transmissions of management information." With " Notification Unsolicited transmission of management information." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 03, 2003 12:42 AM To: Disman (E-mail) Subject: [Disman] unfixed typo in alarm-mib-15 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 ... > 11) Page 4: "transmissions of management" -> > "transmission of management" (I personally think that > defining "notification" in terms of transmission is a > mistake, but it's too late to re-hash that discussion.) ... The typo "transmissions" -> "transmission" still needs to be fixed. Randy From disman-admin@ietf.org Wed Oct 8 16:51: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 QAA08655 for ; Wed, 8 Oct 2003 16:51:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LGw-00019k-Pc; Wed, 08 Oct 2003 16:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LG0-0000zU-PR for disman@optimus.ietf.org; Wed, 08 Oct 2003 16:50:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08637 for ; Wed, 8 Oct 2003 16:49:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7LFy-0004Fv-00 for disman@ietf.org; Wed, 08 Oct 2003 16:50:02 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7LFy-0004Fs-00 for disman@ietf.org; Wed, 08 Oct 2003 16:50:02 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7LFx-0004PF-00 for disman@ietf.org; Wed, 08 Oct 2003 13:50:01 -0700 Message-ID: <005601c38ddd$c6cfc5a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D85FF1@zcard0ka.ca.nortel.com> Subject: Re: [Disman] zero-based counters in draft-ietf-disman-alarm-mib-15.txt? X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 8 Oct 2003 13:50:15 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Wednesday, October 08, 2003 1:26 PM > Subject: RE: [Disman] zero-based counters in draft-ietf-disman-alarm-mib-15.txt? ... > Do we really feel that the current description and data type will result in > non-interoperable implementations? Other than the fact there was a neater > data type that we could have used instead, I don't really see a problem > here. I think the text is sufficient for people to know to start the thing > at 0 if nothing has happened. ... If this is the intended semantic, then we really really should use the ZeroBasedCounter32 TC. Section 4.6.1.2 of the MIB review guidelines seems to be saying that if a counter is required to start at zero, then the TC is the appropriate type to use. If you disagree, then we should move that discussion to the mib review list to find out what the reviewer consensus is, and to perhaps follow up with a clarification to draft-ietf-ops-mib-review-guidelines-02.txt to make it clear what the strength of the recommendation there is. (From the perspective of a former tool vendor, I can say that using the ZeroBasedCounter32 TC is preferable, since would enable automatic generation of initialization code for the counter. Just saying "Counter32" would mean that some human would need to put in the initialization code.) Randy From exim@www1.ietf.org Wed Oct 8 16:51:24 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 QAA08670 for ; Wed, 8 Oct 2003 16:51:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LGy-0001AW-36 for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 16:51:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Kp4kx004486 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 16:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LGx-0001AH-Vt for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 16:51:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08649 for ; Wed, 8 Oct 2003 16:50:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7LGv-0004GO-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 16:51:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7LGv-0004GL-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 16:51:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LGw-00019k-Pc; Wed, 08 Oct 2003 16:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LG0-0000zU-PR for disman@optimus.ietf.org; Wed, 08 Oct 2003 16:50:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08637 for ; Wed, 8 Oct 2003 16:49:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7LFy-0004Fv-00 for disman@ietf.org; Wed, 08 Oct 2003 16:50:02 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7LFy-0004Fs-00 for disman@ietf.org; Wed, 08 Oct 2003 16:50:02 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7LFx-0004PF-00 for disman@ietf.org; Wed, 08 Oct 2003 13:50:01 -0700 Message-ID: <005601c38ddd$c6cfc5a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D85FF1@zcard0ka.ca.nortel.com> Subject: Re: [Disman] zero-based counters in draft-ietf-disman-alarm-mib-15.txt? X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 8 Oct 2003 13:50:15 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Wednesday, October 08, 2003 1:26 PM > Subject: RE: [Disman] zero-based counters in draft-ietf-disman-alarm-mib-15.txt? ... > Do we really feel that the current description and data type will result in > non-interoperable implementations? Other than the fact there was a neater > data type that we could have used instead, I don't really see a problem > here. I think the text is sufficient for people to know to start the thing > at 0 if nothing has happened. ... If this is the intended semantic, then we really really should use the ZeroBasedCounter32 TC. Section 4.6.1.2 of the MIB review guidelines seems to be saying that if a counter is required to start at zero, then the TC is the appropriate type to use. If you disagree, then we should move that discussion to the mib review list to find out what the reviewer consensus is, and to perhaps follow up with a clarification to draft-ietf-ops-mib-review-guidelines-02.txt to make it clear what the strength of the recommendation there is. (From the perspective of a former tool vendor, I can say that using the ZeroBasedCounter32 TC is preferable, since would enable automatic generation of initialization code for the counter. Just saying "Counter32" would mean that some human would need to put in the initialization code.) Randy From disman-admin@ietf.org Wed Oct 8 17:04:24 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 RAA09198 for ; Wed, 8 Oct 2003 17:04:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LTV-00021t-5l; Wed, 08 Oct 2003 17:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LTD-00021G-1g for disman@optimus.ietf.org; Wed, 08 Oct 2003 17:03:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09153 for ; Wed, 8 Oct 2003 17:03:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7LTA-0004RP-00 for disman@ietf.org; Wed, 08 Oct 2003 17:03:40 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7LTA-0004RM-00 for disman@ietf.org; Wed, 08 Oct 2003 17:03:40 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7LTA-0003wu-00 for disman@ietf.org; Wed, 08 Oct 2003 14:03:40 -0700 Message-ID: <006301c38ddf$aebdbec0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] section 3.7 of alarm -15- 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, 8 Oct 2003 14:03:54 -0700 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 ... > 28) Section 3.7: "This format allows for the storage of any Trap > or Notification that can be defined using SMIv1 or SMIv2." > Not quite consistent with definition of "Notification"; > suggest "instance of any TRAP-TYPE or NOTIFICATION-TYPE", > though I think talking about SMIv1 and SMIv2 isn't helpful here. > See #47 below. > > Sharon-> I actually meant the SMI. ... How about this proposed replacement text: "This format allows for the storage of any Trap or Notification type that can be defined using the SMI, or can be carried by SNMP." Randy From exim@www1.ietf.org Wed Oct 8 17:04: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 RAA09215 for ; Wed, 8 Oct 2003 17:04:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LTZ-00024V-CC for disman-archive@odin.ietf.org; Wed, 08 Oct 2003 17:04:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98L45MG007957 for disman-archive@odin.ietf.org; Wed, 8 Oct 2003 17:04:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LTZ-00024G-6y for disman-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 17:04:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09185 for ; Wed, 8 Oct 2003 17:03:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7LTW-0004SI-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 17:04:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7LTW-0004SF-00 for disman-web-archive@ietf.org; Wed, 08 Oct 2003 17:04:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LTV-00021t-5l; Wed, 08 Oct 2003 17:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LTD-00021G-1g for disman@optimus.ietf.org; Wed, 08 Oct 2003 17:03:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09153 for ; Wed, 8 Oct 2003 17:03:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7LTA-0004RP-00 for disman@ietf.org; Wed, 08 Oct 2003 17:03:40 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1A7LTA-0004RM-00 for disman@ietf.org; Wed, 08 Oct 2003 17:03:40 -0400 Received: from h-68-165-65-7.snvacaid.dynamic.covad.net ([68.165.65.7] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A7LTA-0003wu-00 for disman@ietf.org; Wed, 08 Oct 2003 14:03:40 -0700 Message-ID: <006301c38ddf$aebdbec0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408B4978E@zcard0ka.ca.nortel.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] section 3.7 of alarm -15- 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, 8 Oct 2003 14:03:54 -0700 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 ... > 28) Section 3.7: "This format allows for the storage of any Trap > or Notification that can be defined using SMIv1 or SMIv2." > Not quite consistent with definition of "Notification"; > suggest "instance of any TRAP-TYPE or NOTIFICATION-TYPE", > though I think talking about SMIv1 and SMIv2 isn't helpful here. > See #47 below. > > Sharon-> I actually meant the SMI. ... How about this proposed replacement text: "This format allows for the storage of any Trap or Notification type that can be defined using the SMI, or can be carried by SNMP." Randy From disman-admin@ietf.org Thu Oct 9 04:51: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 EAA12220 for ; Thu, 9 Oct 2003 04:51:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7WVh-0005Y6-BO; Thu, 09 Oct 2003 04:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7WVB-0005X6-4m for disman@optimus.ietf.org; Thu, 09 Oct 2003 04:50:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12208 for ; Thu, 9 Oct 2003 04:50:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7WV7-0003hW-00 for disman@ietf.org; Thu, 09 Oct 2003 04:50:26 -0400 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by ietf-mx with esmtp (Exim 4.12) id 1A7WV7-0003hS-00 for disman@ietf.org; Thu, 09 Oct 2003 04:50:25 -0400 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h998nmPU009730 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 9 Oct 2003 10:49:48 +0200 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h998nmVd001131; Thu, 9 Oct 2003 10:49:48 +0200 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) id h998nmMD001127; Thu, 9 Oct 2003 10:49:48 +0200 Message-Id: <200310090849.h998nmMD001127@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: disman@ietf.org In-reply-to: <005601c38ddd$c6cfc5a0$7f1afea9@oemcomputer> (randy_presuhn@mindspring.com) Subject: Re: [Disman] zero-based counters in draft-ietf-disman-alarm-mib-15.txt? References: <3549C09B853DD5119B540002A52CDD3408D85FF1@zcard0ka.ca.nortel.com> <005601c38ddd$c6cfc5a0$7f1afea9@oemcomputer> X-IBRFilter-SpamReport: -9.9 () IN_REP_TO,REFERENCES X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 10:49:48 +0200 >>>>> Randy Presuhn writes: Randy> (From the perspective of a former tool vendor, I can say that Randy> using the ZeroBasedCounter32 TC is preferable, since would Randy> enable automatic generation of initialization code for the Randy> counter. Just saying "Counter32" would mean that some human Randy> would need to put in the initialization code.) Same on the manager side. A Counter32 translates into "a single sample has absolutely no meaning" while ZeroBasedCounter32 translates into "a single sample has some meaning if we assume no wrap-around has occured". And this distinction has implications how you deal with such counters. So if you use zero-based counters, just put in the right TC and move on. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From exim@www1.ietf.org Thu Oct 9 04:51:29 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 EAA12235 for ; Thu, 9 Oct 2003 04:51:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7WVn-0005Zf-E2 for disman-archive@odin.ietf.org; Thu, 09 Oct 2003 04:51:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h998p7mr021426 for disman-archive@odin.ietf.org; Thu, 9 Oct 2003 04:51:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7WVn-0005ZV-3o for disman-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 04:51:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12214 for ; Thu, 9 Oct 2003 04:50:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7WVj-0003hd-00 for disman-web-archive@ietf.org; Thu, 09 Oct 2003 04:51:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7WVj-0003ha-00 for disman-web-archive@ietf.org; Thu, 09 Oct 2003 04:51:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7WVh-0005Y6-BO; Thu, 09 Oct 2003 04:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7WVB-0005X6-4m for disman@optimus.ietf.org; Thu, 09 Oct 2003 04:50:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12208 for ; Thu, 9 Oct 2003 04:50:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7WV7-0003hW-00 for disman@ietf.org; Thu, 09 Oct 2003 04:50:26 -0400 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by ietf-mx with esmtp (Exim 4.12) id 1A7WV7-0003hS-00 for disman@ietf.org; Thu, 09 Oct 2003 04:50:25 -0400 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h998nmPU009730 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 9 Oct 2003 10:49:48 +0200 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id h998nmVd001131; Thu, 9 Oct 2003 10:49:48 +0200 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) id h998nmMD001127; Thu, 9 Oct 2003 10:49:48 +0200 Message-Id: <200310090849.h998nmMD001127@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: disman@ietf.org In-reply-to: <005601c38ddd$c6cfc5a0$7f1afea9@oemcomputer> (randy_presuhn@mindspring.com) Subject: Re: [Disman] zero-based counters in draft-ietf-disman-alarm-mib-15.txt? References: <3549C09B853DD5119B540002A52CDD3408D85FF1@zcard0ka.ca.nortel.com> <005601c38ddd$c6cfc5a0$7f1afea9@oemcomputer> X-IBRFilter-SpamReport: -9.9 () IN_REP_TO,REFERENCES X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Oct 2003 10:49:48 +0200 >>>>> Randy Presuhn writes: Randy> (From the perspective of a former tool vendor, I can say that Randy> using the ZeroBasedCounter32 TC is preferable, since would Randy> enable automatic generation of initialization code for the Randy> counter. Just saying "Counter32" would mean that some human Randy> would need to put in the initialization code.) Same on the manager side. A Counter32 translates into "a single sample has absolutely no meaning" while ZeroBasedCounter32 translates into "a single sample has some meaning if we assume no wrap-around has occured". And this distinction has implications how you deal with such counters. So if you use zero-based counters, just put in the right TC and move on. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From disman-admin@ietf.org Fri Oct 10 09:37:34 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 JAA27651 for ; Fri, 10 Oct 2003 09:37:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7xS0-00036c-VT; Fri, 10 Oct 2003 09:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7xRK-00033i-4t for disman@optimus.ietf.org; Fri, 10 Oct 2003 09:36:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27600 for ; Fri, 10 Oct 2003 09:36:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7xRI-0003Wk-00 for disman@ietf.org; Fri, 10 Oct 2003 09:36:16 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7xRH-0003WK-00 for disman@ietf.org; Fri, 10 Oct 2003 09:36:15 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9ADZgH05637 for ; Fri, 10 Oct 2003 09:35:42 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66S0QT>; Fri, 10 Oct 2003 09:35:42 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D86B8E@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Technical changes to alarm MIB notification types 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: Fri, 10 Oct 2003 09:35:38 -0400 Hi The following is the proposed resolution to Randy-63. Assuming no objection, this item will is closed with no changes to the draft. There has been no response to Randy's call for comments on this change. While all non-editorial changes at this point should be considered 'significant', the throttling changes made to these notifications follows the best practice as outlined in the MIB review guidelines. The names, while goofy, are descriptive. They are the best we currently have. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 03, 2003 1:00 AM To: Disman (E-mail) Subject: [Disman] Technical changes to alarm MIB notification types Hi - WG chair hat on... > 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 ... > 63) alarmActiveState, alarmClearState: the names for these notifications > aren't terribly good. more importantly, something needs to be said > about throttling per draft-ietf-ops-mib-review-guidelines-01.txt > section 4.7 last paragraph, perhaps simply to the effect that these > are "second order" notifications that rely on lower-level throttling > and filter specification. > > Sharon->I did this more in line with the examples in the review > Sharon->guidelines. ... There are some pretty significant changes to the definitions of these two notification types appearing with the -15-draft. I'd like to get a sense of the working group that this particular approach to notification throttling is appropriate for this MIB module. I'd like to hear from those who think this type of throttling is appropriate in this case, as well as from those who would prefer something else. As technical contributor: I still think "alarmActiveState" and "alarmClearState" are lousy names for notifications, and would prefer to *not* do throttling at this layer, but rather higher or lower in the processing stream. Randy From exim@www1.ietf.org Fri Oct 10 09:37:37 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 JAA27667 for ; Fri, 10 Oct 2003 09:37:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7xSF-0003Bp-ES for disman-archive@odin.ietf.org; Fri, 10 Oct 2003 09:37:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ADbFKr012258 for disman-archive@odin.ietf.org; Fri, 10 Oct 2003 09:37:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7xSE-0003BO-8J for disman-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 09:37:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27634 for ; Fri, 10 Oct 2003 09:37:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7xSC-0003Xe-00 for disman-web-archive@ietf.org; Fri, 10 Oct 2003 09:37:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7xSC-0003Xa-00 for disman-web-archive@ietf.org; Fri, 10 Oct 2003 09:37:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7xS0-00036c-VT; Fri, 10 Oct 2003 09:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7xRK-00033i-4t for disman@optimus.ietf.org; Fri, 10 Oct 2003 09:36:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27600 for ; Fri, 10 Oct 2003 09:36:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7xRI-0003Wk-00 for disman@ietf.org; Fri, 10 Oct 2003 09:36:16 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A7xRH-0003WK-00 for disman@ietf.org; Fri, 10 Oct 2003 09:36:15 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9ADZgH05637 for ; Fri, 10 Oct 2003 09:35:42 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66S0QT>; Fri, 10 Oct 2003 09:35:42 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D86B8E@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Technical changes to alarm MIB notification types 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: Fri, 10 Oct 2003 09:35:38 -0400 Hi The following is the proposed resolution to Randy-63. Assuming no objection, this item will is closed with no changes to the draft. There has been no response to Randy's call for comments on this change. While all non-editorial changes at this point should be considered 'significant', the throttling changes made to these notifications follows the best practice as outlined in the MIB review guidelines. The names, while goofy, are descriptive. They are the best we currently have. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 03, 2003 1:00 AM To: Disman (E-mail) Subject: [Disman] Technical changes to alarm MIB notification types Hi - WG chair hat on... > 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 ... > 63) alarmActiveState, alarmClearState: the names for these notifications > aren't terribly good. more importantly, something needs to be said > about throttling per draft-ietf-ops-mib-review-guidelines-01.txt > section 4.7 last paragraph, perhaps simply to the effect that these > are "second order" notifications that rely on lower-level throttling > and filter specification. > > Sharon->I did this more in line with the examples in the review > Sharon->guidelines. ... There are some pretty significant changes to the definitions of these two notification types appearing with the -15-draft. I'd like to get a sense of the working group that this particular approach to notification throttling is appropriate for this MIB module. I'd like to hear from those who think this type of throttling is appropriate in this case, as well as from those who would prefer something else. As technical contributor: I still think "alarmActiveState" and "alarmClearState" are lousy names for notifications, and would prefer to *not* do throttling at this layer, but rather higher or lower in the processing stream. Randy From disman-admin@ietf.org Fri Oct 10 10:34:22 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 KAA00533 for ; Fri, 10 Oct 2003 10:34:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yLB-0006Tr-3c; Fri, 10 Oct 2003 10:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yKc-0006TT-Rf for disman@optimus.ietf.org; Fri, 10 Oct 2003 10:33:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00483 for ; Fri, 10 Oct 2003 10:33:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yKZ-00047D-00 for disman@ietf.org; Fri, 10 Oct 2003 10:33:23 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A7yKZ-00046F-00 for disman@ietf.org; Fri, 10 Oct 2003 10:33:23 -0400 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 h9AEWkK22751 for ; Fri, 10 Oct 2003 10:32:46 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66TB1Y>; Fri, 10 Oct 2003 10:32:46 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D86C64@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] zero-based counters in draft-ietf-disman-alarm-mib-1 5.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: Fri, 10 Oct 2003 10:32:44 -0400 Hi The following is the proposed resolution to Randy-62 and Randy-71. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the Alarm MIB imports section, replace " NOTIFICATION-GROUP FROM SNMPv2-CONF;" With " NOTIFICATION-GROUP FROM SNMPv2-CONF ZeroBasedCounter32 FROM RMON2-MIB;" In the definition of AlarmActiveStatsEntry, replace " alarmActiveStatsActives Counter32," To " alarmActiveStatsActives ZeroBasedCounter32 ," In the object definition, replace " alarmActiveStatsActives OBJECT-TYPE SYNTAX Counter32" With " alarmActiveStatsActives OBJECT-TYPE SYNTAX ZeroBasedCounter32 " In the ITU-ALARM-MIB imports section, replace " MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;" With " MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ZeroBasedCounter32 FROM RMON2-MIB;" In the definition of ItuAlarmActiveStatsEntry, replace " ituAlarmActiveStatsIndeterminates Counter32, ituAlarmActiveStatsCriticals Counter32, ituAlarmActiveStatsMajors Counter32, ituAlarmActiveStatsMinors Counter32, ituAlarmActiveStatsWarnings Counter32" With " ituAlarmActiveStatsIndeterminates ZeroBasedCounter32 , ituAlarmActiveStatsCriticals ZeroBasedCounter32 , ituAlarmActiveStatsMajors ZeroBasedCounter32 , ituAlarmActiveStatsMinors ZeroBasedCounter32 , ituAlarmActiveStatsWarnings ZeroBasedCounter32 " In the object definitions, replace " ituAlarmActiveStatsIndeterminates OBJECT-TYPE SYNTAX Counter32 " With "ituAlarmActiveStatsIndeterminates OBJECT-TYPE SYNTAX ZeroBasedCounter32 " " ituAlarmActiveStatsCriticals OBJECT-TYPE SYNTAX Counter32" With " ituAlarmActiveStatsCriticals OBJECT-TYPE SYNTAX ZeroBasedCounter32 " " ituAlarmActiveStatsMajors OBJECT-TYPE SYNTAX Counter32" With " ituAlarmActiveStatsMajors OBJECT-TYPE SYNTAX ZeroBasedCounter32 " " ituAlarmActiveStatsMinors OBJECT-TYPE SYNTAX Counter32" With " ituAlarmActiveStatsMinors OBJECT-TYPE SYNTAX ZeroBasedCounter32 " " ituAlarmActiveStatsWarnings OBJECT-TYPE SYNTAX Counter32" With " ituAlarmActiveStatsWarnings OBJECT-TYPE SYNTAX ZeroBasedCounter32 " Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 02, 2003 10:54 PM To: Disman (E-mail) Subject: [Disman] zero-based counters in 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 ... > 62) alarmActiveStatsActives, the SYNTAX says this is a Counter32, > but the DESCRIPTION sure makes it sound like it's supposed to > be zero-based. > > 71) ituAlarmActiveStatsIndeterminates, > ituAlarmActiveStatsCriticals, > ituAlarmActiveStatsMajors, > ituAlarmActiveStatsMinors, and > ituAlarmActiveStatsWarnings are all Counter32, but their > DESCRIPTIONs sound like they're assumed to be zero-based. > > Sharon-> Counter32 can have a value of 0. ... Let me put it another way: if none of these events have occured since system restart, what will the value of these objects be? a) zero, since the descriptions say they are counts "since system restart" if this is the case, they should use the ZeroBasedCounter32 TC b) not predictable, given the defnition of Counter32 in RFC 2578 clause 7.1.6 if this is the case, then the "since system restart" words are misleading Randy (technical contributor) From exim@www1.ietf.org Fri Oct 10 10:34:24 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 KAA00548 for ; Fri, 10 Oct 2003 10:34:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yLC-0006UQ-Tp for disman-archive@odin.ietf.org; Fri, 10 Oct 2003 10:34:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AEY2Gm024945 for disman-archive@odin.ietf.org; Fri, 10 Oct 2003 10:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yLC-0006UG-QJ for disman-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 10:34:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00511 for ; Fri, 10 Oct 2003 10:33:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yLA-000482-00 for disman-web-archive@ietf.org; Fri, 10 Oct 2003 10:34:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7yLA-00047z-00 for disman-web-archive@ietf.org; Fri, 10 Oct 2003 10:34:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yLB-0006Tr-3c; Fri, 10 Oct 2003 10:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7yKc-0006TT-Rf for disman@optimus.ietf.org; Fri, 10 Oct 2003 10:33:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00483 for ; Fri, 10 Oct 2003 10:33:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7yKZ-00047D-00 for disman@ietf.org; Fri, 10 Oct 2003 10:33:23 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A7yKZ-00046F-00 for disman@ietf.org; Fri, 10 Oct 2003 10:33:23 -0400 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 h9AEWkK22751 for ; Fri, 10 Oct 2003 10:32:46 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66TB1Y>; Fri, 10 Oct 2003 10:32:46 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D86C64@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] zero-based counters in draft-ietf-disman-alarm-mib-1 5.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: Fri, 10 Oct 2003 10:32:44 -0400 Hi The following is the proposed resolution to Randy-62 and Randy-71. Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the Alarm MIB imports section, replace " NOTIFICATION-GROUP FROM SNMPv2-CONF;" With " NOTIFICATION-GROUP FROM SNMPv2-CONF ZeroBasedCounter32 FROM RMON2-MIB;" In the definition of AlarmActiveStatsEntry, replace " alarmActiveStatsActives Counter32," To " alarmActiveStatsActives ZeroBasedCounter32 ," In the object definition, replace " alarmActiveStatsActives OBJECT-TYPE SYNTAX Counter32" With " alarmActiveStatsActives OBJECT-TYPE SYNTAX ZeroBasedCounter32 " In the ITU-ALARM-MIB imports section, replace " MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;" With " MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ZeroBasedCounter32 FROM RMON2-MIB;" In the definition of ItuAlarmActiveStatsEntry, replace " ituAlarmActiveStatsIndeterminates Counter32, ituAlarmActiveStatsCriticals Counter32, ituAlarmActiveStatsMajors Counter32, ituAlarmActiveStatsMinors Counter32, ituAlarmActiveStatsWarnings Counter32" With " ituAlarmActiveStatsIndeterminates ZeroBasedCounter32 , ituAlarmActiveStatsCriticals ZeroBasedCounter32 , ituAlarmActiveStatsMajors ZeroBasedCounter32 , ituAlarmActiveStatsMinors ZeroBasedCounter32 , ituAlarmActiveStatsWarnings ZeroBasedCounter32 " In the object definitions, replace " ituAlarmActiveStatsIndeterminates OBJECT-TYPE SYNTAX Counter32 " With "ituAlarmActiveStatsIndeterminates OBJECT-TYPE SYNTAX ZeroBasedCounter32 " " ituAlarmActiveStatsCriticals OBJECT-TYPE SYNTAX Counter32" With " ituAlarmActiveStatsCriticals OBJECT-TYPE SYNTAX ZeroBasedCounter32 " " ituAlarmActiveStatsMajors OBJECT-TYPE SYNTAX Counter32" With " ituAlarmActiveStatsMajors OBJECT-TYPE SYNTAX ZeroBasedCounter32 " " ituAlarmActiveStatsMinors OBJECT-TYPE SYNTAX Counter32" With " ituAlarmActiveStatsMinors OBJECT-TYPE SYNTAX ZeroBasedCounter32 " " ituAlarmActiveStatsWarnings OBJECT-TYPE SYNTAX Counter32" With " ituAlarmActiveStatsWarnings OBJECT-TYPE SYNTAX ZeroBasedCounter32 " Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 02, 2003 10:54 PM To: Disman (E-mail) Subject: [Disman] zero-based counters in 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 ... > 62) alarmActiveStatsActives, the SYNTAX says this is a Counter32, > but the DESCRIPTION sure makes it sound like it's supposed to > be zero-based. > > 71) ituAlarmActiveStatsIndeterminates, > ituAlarmActiveStatsCriticals, > ituAlarmActiveStatsMajors, > ituAlarmActiveStatsMinors, and > ituAlarmActiveStatsWarnings are all Counter32, but their > DESCRIPTIONs sound like they're assumed to be zero-based. > > Sharon-> Counter32 can have a value of 0. ... Let me put it another way: if none of these events have occured since system restart, what will the value of these objects be? a) zero, since the descriptions say they are counts "since system restart" if this is the case, they should use the ZeroBasedCounter32 TC b) not predictable, given the defnition of Counter32 in RFC 2578 clause 7.1.6 if this is the case, then the "since system restart" words are misleading Randy (technical contributor) From disman-admin@ietf.org Fri Oct 10 12:37: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 MAA06368 for ; Fri, 10 Oct 2003 12:37:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80GC-00085l-SY; Fri, 10 Oct 2003 12:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80G2-000854-M1 for disman@optimus.ietf.org; Fri, 10 Oct 2003 12:36:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06350 for ; Fri, 10 Oct 2003 12:36:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A80G0-00061k-00 for disman@ietf.org; Fri, 10 Oct 2003 12:36:48 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A80G0-00061O-00 for disman@ietf.org; Fri, 10 Oct 2003 12:36:48 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9AGaG113764 for ; Fri, 10 Oct 2003 12:36:16 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66T12Q>; Fri, 10 Oct 2003 12:36:16 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D86DF7@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] definition of Alarm Raise in Comments on 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: Fri, 10 Oct 2003 12:36:14 -0400 Hi The following is the proposed resolution to Randy-14 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 3.1, replace " Alarm Raise The initial detection of the fault indicated by an alarm or any number of alarm states later entered, except clear. A Notification SHOULD be sent on alarm raise." With " Alarm Raise The initial detection of the fault indicated by an alarm or any number of alarm states later entered, except clear." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 03, 2003 12:49 AM To: Disman (E-mail) Subject: [Disman] definition of Alarm Raise in Comments on 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 ... > 14) Page 4: "A notification SHOULD be sent on alarm raise." > Given the definition of notification, and the role of RFC > 3413, this sentence should be deleted. Whether a notification > should be sent depends on whether some manager is interested > in it and has configured the SNMP-NOTIFICATION-MIB and > SNMP-TARGET-MIB accordingly. > > Sharon -> This was explicitly discussed and wg consensus was that it > was OK to indicate a preference for sending notifications. ... Perhaps I'm just getting denser, but I still don't see how this belongs in the definition for "Alarm Raise". The current text says: Alarm Raise The initial detection of the fault indicated by an alarm or any number of alarm states later entered, except clear. A Notification SHOULD be sent on alarm raise. The second sentence simply does not belong in the definition. Furthermore, the SHOULD language directly contradicts the normal functioning of this MIB module, which provides a means of controlling whether a Notification is issued, and the operation of RFC 3413, which controls whether it is sent anywhere. Randy (technical contributor) From exim@www1.ietf.org Fri Oct 10 12:37: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 MAA06386 for ; Fri, 10 Oct 2003 12:37:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80GK-0008B1-Jk for disman-archive@odin.ietf.org; Fri, 10 Oct 2003 12:37:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AGb7U5031383 for disman-archive@odin.ietf.org; Fri, 10 Oct 2003 12:37:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80GH-00088O-LO for disman-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 12:37:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06359 for ; Fri, 10 Oct 2003 12:36:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A80GF-00061v-00 for disman-web-archive@ietf.org; Fri, 10 Oct 2003 12:37:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A80GF-00061s-00 for disman-web-archive@ietf.org; Fri, 10 Oct 2003 12:37:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80GC-00085l-SY; Fri, 10 Oct 2003 12:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80G2-000854-M1 for disman@optimus.ietf.org; Fri, 10 Oct 2003 12:36:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06350 for ; Fri, 10 Oct 2003 12:36:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A80G0-00061k-00 for disman@ietf.org; Fri, 10 Oct 2003 12:36:48 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A80G0-00061O-00 for disman@ietf.org; Fri, 10 Oct 2003 12:36:48 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9AGaG113764 for ; Fri, 10 Oct 2003 12:36:16 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66T12Q>; Fri, 10 Oct 2003 12:36:16 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D86DF7@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] definition of Alarm Raise in Comments on 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: Fri, 10 Oct 2003 12:36:14 -0400 Hi The following is the proposed resolution to Randy-14 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 3.1, replace " Alarm Raise The initial detection of the fault indicated by an alarm or any number of alarm states later entered, except clear. A Notification SHOULD be sent on alarm raise." With " Alarm Raise The initial detection of the fault indicated by an alarm or any number of alarm states later entered, except clear." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 03, 2003 12:49 AM To: Disman (E-mail) Subject: [Disman] definition of Alarm Raise in Comments on 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 ... > 14) Page 4: "A notification SHOULD be sent on alarm raise." > Given the definition of notification, and the role of RFC > 3413, this sentence should be deleted. Whether a notification > should be sent depends on whether some manager is interested > in it and has configured the SNMP-NOTIFICATION-MIB and > SNMP-TARGET-MIB accordingly. > > Sharon -> This was explicitly discussed and wg consensus was that it > was OK to indicate a preference for sending notifications. ... Perhaps I'm just getting denser, but I still don't see how this belongs in the definition for "Alarm Raise". The current text says: Alarm Raise The initial detection of the fault indicated by an alarm or any number of alarm states later entered, except clear. A Notification SHOULD be sent on alarm raise. The second sentence simply does not belong in the definition. Furthermore, the SHOULD language directly contradicts the normal functioning of this MIB module, which provides a means of controlling whether a Notification is issued, and the operation of RFC 3413, which controls whether it is sent anywhere. Randy (technical contributor) From disman-admin@ietf.org Fri Oct 10 14:19: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 OAA10584 for ; Fri, 10 Oct 2003 14:19:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81qv-0007WC-Cv; Fri, 10 Oct 2003 14:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81qm-0007Vu-CR for disman@optimus.ietf.org; Fri, 10 Oct 2003 14:18:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10565 for ; Fri, 10 Oct 2003 14:18:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81qj-0007D5-00 for disman@ietf.org; Fri, 10 Oct 2003 14:18:49 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A81qi-0007Cp-00 for disman@ietf.org; Fri, 10 Oct 2003 14:18:49 -0400 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 h9AIIBK07104 for ; Fri, 10 Oct 2003 14:18:12 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66TGWD>; Fri, 10 Oct 2003 14:18:12 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D86F05@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: Fri, 10 Oct 2003 14:18:12 -0400 Hi The following is the proposed resolution to Randy-74-4. Assuming no objection, this item will is closed with no changes to the draft. In the definition of alarmActiveEntry is " "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared." One of the indices into this table is DataAndTime object. This table therefore will not wrap, so discussing what happens when the table wraps does not make sense. The statement that indicates that entries are removed when the alarm is cleared implies that entries stay in the table while they are active. End of story. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 03, 2003 1:31 AM To: Disman (E-mail) Subject: [Disman] "table wrapping" in alarm MIB -15- 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 ... ... > 75-4) I missed anything like an "alarmActiveMaximum", yet the document > doesn't seem to describe what should happen if there are too many > active alarms, as might happen if there are lots of instances of a > particular type of resource, and an administrator inadvertently > specifies a frequent, innocuous event as being of interest. > > Sharon->The design was normal table wrapping ... What is "normal table wrapping"? This is a new one for me. The document still needs to specify what happens. For example, if the alarm raise is lost, will the clear also be siletly suppressed? Even with frequency throttling in place, if alarms are sufficiently long lived there may still accumulate a very large number of them. Randy From exim@www1.ietf.org Fri Oct 10 14:19:28 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 OAA10599 for ; Fri, 10 Oct 2003 14:19:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81qz-0007X5-Up for disman-archive@odin.ietf.org; Fri, 10 Oct 2003 14:19:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AIJ5bG028951 for disman-archive@odin.ietf.org; Fri, 10 Oct 2003 14:19:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81qz-0007Ws-QM for disman-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 14:19:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10576 for ; Fri, 10 Oct 2003 14:18:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81qx-0007DM-00 for disman-web-archive@ietf.org; Fri, 10 Oct 2003 14:19:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A81qw-0007DJ-00 for disman-web-archive@ietf.org; Fri, 10 Oct 2003 14:19:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81qv-0007WC-Cv; Fri, 10 Oct 2003 14:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81qm-0007Vu-CR for disman@optimus.ietf.org; Fri, 10 Oct 2003 14:18:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10565 for ; Fri, 10 Oct 2003 14:18:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81qj-0007D5-00 for disman@ietf.org; Fri, 10 Oct 2003 14:18:49 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A81qi-0007Cp-00 for disman@ietf.org; Fri, 10 Oct 2003 14:18:49 -0400 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 h9AIIBK07104 for ; Fri, 10 Oct 2003 14:18:12 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66TGWD>; Fri, 10 Oct 2003 14:18:12 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408D86F05@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: Fri, 10 Oct 2003 14:18:12 -0400 Hi The following is the proposed resolution to Randy-74-4. Assuming no objection, this item will is closed with no changes to the draft. In the definition of alarmActiveEntry is " "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared." One of the indices into this table is DataAndTime object. This table therefore will not wrap, so discussing what happens when the table wraps does not make sense. The statement that indicates that entries are removed when the alarm is cleared implies that entries stay in the table while they are active. End of story. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 03, 2003 1:31 AM To: Disman (E-mail) Subject: [Disman] "table wrapping" in alarm MIB -15- 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 ... ... > 75-4) I missed anything like an "alarmActiveMaximum", yet the document > doesn't seem to describe what should happen if there are too many > active alarms, as might happen if there are lots of instances of a > particular type of resource, and an administrator inadvertently > specifies a frequent, innocuous event as being of interest. > > Sharon->The design was normal table wrapping ... What is "normal table wrapping"? This is a new one for me. The document still needs to specify what happens. For example, if the alarm raise is lost, will the clear also be siletly suppressed? Even with frequency throttling in place, if alarms are sufficiently long lived there may still accumulate a very large number of them. Randy From disman-admin@ietf.org Fri Oct 10 15:00:24 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 PAA12743 for ; Fri, 10 Oct 2003 15:00:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82Uc-0002lA-P0; Fri, 10 Oct 2003 15:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82UZ-0002kU-LC for disman@optimus.ietf.org; Fri, 10 Oct 2003 14:59:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12699 for ; Fri, 10 Oct 2003 14:59:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A82UW-00001w-00 for disman@ietf.org; Fri, 10 Oct 2003 14:59:56 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A82UV-00001P-00 for disman@ietf.org; Fri, 10 Oct 2003 14:59:55 -0400 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 h9AIxMK12962 for ; Fri, 10 Oct 2003 14:59:23 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66THVS>; Fri, 10 Oct 2003 14:59:22 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408DFA4CC@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: Fri, 10 Oct 2003 14:59:18 -0400 Hi For every A, there is a B. For every B there is an A. Therefore the # of A = # of B. QED. The number of itu active alarms is equal to the active alarms for the whole system, if we define the whole system to be the whole alarm system. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 3:23 PM To: Disman (E-mail) Subject: Re: [Disman] Section 5.1 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:01 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 is closed with no changes to the draft. > > Section 4.1.1 says > > "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." > > Therefore the distinction that Randy is making is a moot point. ... I disagree. The current text effectively says that for each entry in the alarmModelTable there will be zero or one entries in any given specific MIB alarm model table, though one might argue whether the limitations of alarmModelSpecificPointer result in a total limit of 1:(0,1) or 1:(0,n) where n is the number of specific models possible. So my question still stands: Are the numbers in ituAlarmActiveStatsTable for stuff modeled using the ituAlarmTable, or for the whole system? Randy From exim@www1.ietf.org Fri Oct 10 15:00: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 PAA12759 for ; Fri, 10 Oct 2003 15:00:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82Ue-0002lw-No for disman-archive@odin.ietf.org; Fri, 10 Oct 2003 15:00:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AJ04ES010650 for disman-archive@odin.ietf.org; Fri, 10 Oct 2003 15:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82Ue-0002lh-BT for disman-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 15:00:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12705 for ; Fri, 10 Oct 2003 14:59:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A82Ub-00002C-00 for disman-web-archive@ietf.org; Fri, 10 Oct 2003 15:00:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A82Ua-000029-00 for disman-web-archive@ietf.org; Fri, 10 Oct 2003 15:00:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82Uc-0002lA-P0; Fri, 10 Oct 2003 15:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A82UZ-0002kU-LC for disman@optimus.ietf.org; Fri, 10 Oct 2003 14:59:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12699 for ; Fri, 10 Oct 2003 14:59:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A82UW-00001w-00 for disman@ietf.org; Fri, 10 Oct 2003 14:59:56 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A82UV-00001P-00 for disman@ietf.org; Fri, 10 Oct 2003 14:59:55 -0400 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 h9AIxMK12962 for ; Fri, 10 Oct 2003 14:59:23 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66THVS>; Fri, 10 Oct 2003 14:59:22 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408DFA4CC@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: Fri, 10 Oct 2003 14:59:18 -0400 Hi For every A, there is a B. For every B there is an A. Therefore the # of A = # of B. QED. The number of itu active alarms is equal to the active alarms for the whole system, if we define the whole system to be the whole alarm system. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 3:23 PM To: Disman (E-mail) Subject: Re: [Disman] Section 5.1 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:01 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 is closed with no changes to the draft. > > Section 4.1.1 says > > "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." > > Therefore the distinction that Randy is making is a moot point. ... I disagree. The current text effectively says that for each entry in the alarmModelTable there will be zero or one entries in any given specific MIB alarm model table, though one might argue whether the limitations of alarmModelSpecificPointer result in a total limit of 1:(0,1) or 1:(0,n) where n is the number of specific models possible. So my question still stands: Are the numbers in ituAlarmActiveStatsTable for stuff modeled using the ituAlarmTable, or for the whole system? Randy From disman-admin@ietf.org Fri Oct 10 15:43:29 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 PAA16387 for ; Fri, 10 Oct 2003 15:43:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83AD-0006X8-2m; Fri, 10 Oct 2003 15:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A839s-0006W6-CS for disman@optimus.ietf.org; Fri, 10 Oct 2003 15:42:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16168 for ; Fri, 10 Oct 2003 15:42:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A839q-0000c8-00 for disman@ietf.org; Fri, 10 Oct 2003 15:42:38 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A839q-0000b3-00 for disman@ietf.org; Fri, 10 Oct 2003 15:42:38 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9AJg2122033 for ; Fri, 10 Oct 2003 15:42:02 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66T2S6>; Fri, 10 Oct 2003 15:42:02 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408DFA54C@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] LocalSnmpEngineOrZeroLenStr in draft-ietf-disman-al arm-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: Fri, 10 Oct 2003 15:41:59 -0400 Hi The following is the proposed resolution to Randy-74-4. Assuming no objection, this item will is closed with no changes to the draft. I don't get your issue with the word instantiate (http://dictionary.reference.com/search?r=2&q=instantiate). Textual conventions are abstract. When we use them in object definitions they are concrete. The 'Local' refers to where the alarm originated. So on a distributed manager, there could potentially be different engine IDs. This is explained in the instantiation of the TC. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 02, 2003 11:18 PM To: Disman (E-mail) Subject: [Disman] LocalSnmpEngineOrZeroLenStr in 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 ... > 44) page 15 (LocalSnmpEngineOrZeroLenStr): where the DESCRIPTION > talks about "instantiation" doesn't make sense. I think it's > referring to use of the TC in an OBJECT-TYPE definition, rather > than object instantiation. > > Sharon -> This seems more a wordsmith thing. ... The DESCRIPTION still doesn't make sense. It currently says: "An SNMP Engine ID or a zero-length string. The instantiation of this object will provide guidance on when this will be an SNMP Engine ID and when it will be a zero lengths string" This is a TC definition, so "instantiation of this object will provide guidance" makes no sense at all to me. In both cases where this TC is used, the conditions for a zero-length string value are the same: either the notification came from a protocol (SNMPv1 is not the only one! don't forget SNMPv2c) which doesn't use SNMP Engine ID, or all entries in the table currently have the same Engine ID. (I guess that means that when one arrives from some other engine, all these objects' values will change from zero-length string back to their "real" values. Am I the only person bothered by this?) Randy From exim@www1.ietf.org Fri Oct 10 15:43: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 PAA16418 for ; Fri, 10 Oct 2003 15:43:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83AK-0006Zw-9X for disman-archive@odin.ietf.org; Fri, 10 Oct 2003 15:43:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AJh8xu025284 for disman-archive@odin.ietf.org; Fri, 10 Oct 2003 15:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83AK-0006Zj-6K for disman-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 15:43:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16231 for ; Fri, 10 Oct 2003 15:43:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83AI-0000dr-00 for disman-web-archive@ietf.org; Fri, 10 Oct 2003 15:43:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A83AI-0000do-00 for disman-web-archive@ietf.org; Fri, 10 Oct 2003 15:43:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83AD-0006X8-2m; Fri, 10 Oct 2003 15:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A839s-0006W6-CS for disman@optimus.ietf.org; Fri, 10 Oct 2003 15:42:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16168 for ; Fri, 10 Oct 2003 15:42:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A839q-0000c8-00 for disman@ietf.org; Fri, 10 Oct 2003 15:42:38 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A839q-0000b3-00 for disman@ietf.org; Fri, 10 Oct 2003 15:42:38 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9AJg2122033 for ; Fri, 10 Oct 2003 15:42:02 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66T2S6>; Fri, 10 Oct 2003 15:42:02 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408DFA54C@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] LocalSnmpEngineOrZeroLenStr in draft-ietf-disman-al arm-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: Fri, 10 Oct 2003 15:41:59 -0400 Hi The following is the proposed resolution to Randy-74-4. Assuming no objection, this item will is closed with no changes to the draft. I don't get your issue with the word instantiate (http://dictionary.reference.com/search?r=2&q=instantiate). Textual conventions are abstract. When we use them in object definitions they are concrete. The 'Local' refers to where the alarm originated. So on a distributed manager, there could potentially be different engine IDs. This is explained in the instantiation of the TC. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 02, 2003 11:18 PM To: Disman (E-mail) Subject: [Disman] LocalSnmpEngineOrZeroLenStr in 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 ... > 44) page 15 (LocalSnmpEngineOrZeroLenStr): where the DESCRIPTION > talks about "instantiation" doesn't make sense. I think it's > referring to use of the TC in an OBJECT-TYPE definition, rather > than object instantiation. > > Sharon -> This seems more a wordsmith thing. ... The DESCRIPTION still doesn't make sense. It currently says: "An SNMP Engine ID or a zero-length string. The instantiation of this object will provide guidance on when this will be an SNMP Engine ID and when it will be a zero lengths string" This is a TC definition, so "instantiation of this object will provide guidance" makes no sense at all to me. In both cases where this TC is used, the conditions for a zero-length string value are the same: either the notification came from a protocol (SNMPv1 is not the only one! don't forget SNMPv2c) which doesn't use SNMP Engine ID, or all entries in the table currently have the same Engine ID. (I guess that means that when one arrives from some other engine, all these objects' values will change from zero-length string back to their "real" values. Am I the only person bothered by this?) Randy From disman-admin@ietf.org Fri Oct 10 15:46:24 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 PAA16894 for ; Fri, 10 Oct 2003 15:46:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83D6-0006vX-Rl; Fri, 10 Oct 2003 15:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83CC-0006ig-UD for disman@optimus.ietf.org; Fri, 10 Oct 2003 15:45:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16714 for ; Fri, 10 Oct 2003 15:44:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83CB-0000mO-00 for disman@ietf.org; Fri, 10 Oct 2003 15:45:03 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A83CA-0000jw-00 for disman@ietf.org; Fri, 10 Oct 2003 15:45:02 -0400 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 h9AJiUK19979 for ; Fri, 10 Oct 2003 15:44:30 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66T2VP>; Fri, 10 Oct 2003 15:44:30 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408DFA554@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] LocalSnmpEngineOrZeroLenStr in draft-ietf-disman-al arm-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: Fri, 10 Oct 2003 15:44:29 -0400 Hi Oops. Make that Randy-44. Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Friday, October 10, 2003 3:42 PM To: 'Disman (E-mail)' Subject: RE: [Disman] LocalSnmpEngineOrZeroLenStr in draft-ietf-disman-alarm-mib-15.txt Hi The following is the proposed resolution to Randy-74-4. Assuming no objection, this item will is closed with no changes to the draft. I don't get your issue with the word instantiate (http://dictionary.reference.com/search?r=2&q=instantiate). Textual conventions are abstract. When we use them in object definitions they are concrete. The 'Local' refers to where the alarm originated. So on a distributed manager, there could potentially be different engine IDs. This is explained in the instantiation of the TC. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 02, 2003 11:18 PM To: Disman (E-mail) Subject: [Disman] LocalSnmpEngineOrZeroLenStr in 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 ... > 44) page 15 (LocalSnmpEngineOrZeroLenStr): where the DESCRIPTION > talks about "instantiation" doesn't make sense. I think it's > referring to use of the TC in an OBJECT-TYPE definition, rather > than object instantiation. > > Sharon -> This seems more a wordsmith thing. ... The DESCRIPTION still doesn't make sense. It currently says: "An SNMP Engine ID or a zero-length string. The instantiation of this object will provide guidance on when this will be an SNMP Engine ID and when it will be a zero lengths string" This is a TC definition, so "instantiation of this object will provide guidance" makes no sense at all to me. In both cases where this TC is used, the conditions for a zero-length string value are the same: either the notification came from a protocol (SNMPv1 is not the only one! don't forget SNMPv2c) which doesn't use SNMP Engine ID, or all entries in the table currently have the same Engine ID. (I guess that means that when one arrives from some other engine, all these objects' values will change from zero-length string back to their "real" values. Am I the only person bothered by this?) Randy From exim@www1.ietf.org Fri Oct 10 15:46: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 PAA16901 for ; Fri, 10 Oct 2003 15:46:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83D8-0006xA-KY for disman-archive@odin.ietf.org; Fri, 10 Oct 2003 15:46:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AJk2JT026722 for disman-archive@odin.ietf.org; Fri, 10 Oct 2003 15:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83D7-0006wA-SK for disman-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 15:46:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16842 for ; Fri, 10 Oct 2003 15:45:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83D6-0000op-00 for disman-web-archive@ietf.org; Fri, 10 Oct 2003 15:46:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A83D5-0000om-00 for disman-web-archive@ietf.org; Fri, 10 Oct 2003 15:45:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83D6-0006vX-Rl; Fri, 10 Oct 2003 15:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A83CC-0006ig-UD for disman@optimus.ietf.org; Fri, 10 Oct 2003 15:45:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16714 for ; Fri, 10 Oct 2003 15:44:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A83CB-0000mO-00 for disman@ietf.org; Fri, 10 Oct 2003 15:45:03 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A83CA-0000jw-00 for disman@ietf.org; Fri, 10 Oct 2003 15:45:02 -0400 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 h9AJiUK19979 for ; Fri, 10 Oct 2003 15:44:30 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66T2VP>; Fri, 10 Oct 2003 15:44:30 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408DFA554@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] LocalSnmpEngineOrZeroLenStr in draft-ietf-disman-al arm-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: Fri, 10 Oct 2003 15:44:29 -0400 Hi Oops. Make that Randy-44. Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Friday, October 10, 2003 3:42 PM To: 'Disman (E-mail)' Subject: RE: [Disman] LocalSnmpEngineOrZeroLenStr in draft-ietf-disman-alarm-mib-15.txt Hi The following is the proposed resolution to Randy-74-4. Assuming no objection, this item will is closed with no changes to the draft. I don't get your issue with the word instantiate (http://dictionary.reference.com/search?r=2&q=instantiate). Textual conventions are abstract. When we use them in object definitions they are concrete. The 'Local' refers to where the alarm originated. So on a distributed manager, there could potentially be different engine IDs. This is explained in the instantiation of the TC. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 02, 2003 11:18 PM To: Disman (E-mail) Subject: [Disman] LocalSnmpEngineOrZeroLenStr in 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 ... > 44) page 15 (LocalSnmpEngineOrZeroLenStr): where the DESCRIPTION > talks about "instantiation" doesn't make sense. I think it's > referring to use of the TC in an OBJECT-TYPE definition, rather > than object instantiation. > > Sharon -> This seems more a wordsmith thing. ... The DESCRIPTION still doesn't make sense. It currently says: "An SNMP Engine ID or a zero-length string. The instantiation of this object will provide guidance on when this will be an SNMP Engine ID and when it will be a zero lengths string" This is a TC definition, so "instantiation of this object will provide guidance" makes no sense at all to me. In both cases where this TC is used, the conditions for a zero-length string value are the same: either the notification came from a protocol (SNMPv1 is not the only one! don't forget SNMPv2c) which doesn't use SNMP Engine ID, or all entries in the table currently have the same Engine ID. (I guess that means that when one arrives from some other engine, all these objects' values will change from zero-length string back to their "real" values. Am I the only person bothered by this?) Randy From disman-admin@ietf.org Fri Oct 10 23:51:58 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 XAA06672 for ; Fri, 10 Oct 2003 23:51:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8AmV-0001N2-ML; Fri, 10 Oct 2003 23:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Alm-0001Kw-N6 for disman@optimus.ietf.org; Fri, 10 Oct 2003 23:50:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06630 for ; Fri, 10 Oct 2003 23:50:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8Alj-0007Fa-00 for disman@ietf.org; Fri, 10 Oct 2003 23:50:15 -0400 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1A8Alj-0007FX-00 for disman@ietf.org; Fri, 10 Oct 2003 23:50:15 -0400 Received: from h-68-164-27-209.snvacaid.dynamic.covad.net ([68.164.27.209] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A8Ali-0001W1-00 for disman@ietf.org; Fri, 10 Oct 2003 20:50:14 -0700 Message-ID: <007d01c38faa$d2473480$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408DFA4CC@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 20:50:32 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Friday, October 10, 2003 11:59 AM > Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt > > Hi > > For every A, there is a B. For every B there is an A. Therefore the # of A = > # of B. QED. ... Wrong. The current language says for every B there is an A. It does NOT say that for every A there is a B. Furthermore, if it did, then only ONE extension MIB could exist in a system, due to the way alarmModelSpecificPointer works. If someone defined a DMTF-ALARM-MIB, it could not under your reasoning exist in a system that also supported the ITU alarm stuff. Randy From exim@www1.ietf.org Fri Oct 10 23:52:02 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 XAA06687 for ; Fri, 10 Oct 2003 23:52:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8An5-0001QG-PG for disman-archive@odin.ietf.org; Fri, 10 Oct 2003 23:51:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9B3pdYa005462 for disman-archive@odin.ietf.org; Fri, 10 Oct 2003 23:51:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8An5-0001Q1-44 for disman-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 23:51:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06650 for ; Fri, 10 Oct 2003 23:51:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8An1-0007GA-00 for disman-web-archive@ietf.org; Fri, 10 Oct 2003 23:51:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8An0-0007G7-00 for disman-web-archive@ietf.org; Fri, 10 Oct 2003 23:51:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8AmV-0001N2-ML; Fri, 10 Oct 2003 23:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Alm-0001Kw-N6 for disman@optimus.ietf.org; Fri, 10 Oct 2003 23:50:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06630 for ; Fri, 10 Oct 2003 23:50:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8Alj-0007Fa-00 for disman@ietf.org; Fri, 10 Oct 2003 23:50:15 -0400 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1A8Alj-0007FX-00 for disman@ietf.org; Fri, 10 Oct 2003 23:50:15 -0400 Received: from h-68-164-27-209.snvacaid.dynamic.covad.net ([68.164.27.209] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A8Ali-0001W1-00 for disman@ietf.org; Fri, 10 Oct 2003 20:50:14 -0700 Message-ID: <007d01c38faa$d2473480$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408DFA4CC@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 20:50:32 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Friday, October 10, 2003 11:59 AM > Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt > > Hi > > For every A, there is a B. For every B there is an A. Therefore the # of A = > # of B. QED. ... Wrong. The current language says for every B there is an A. It does NOT say that for every A there is a B. Furthermore, if it did, then only ONE extension MIB could exist in a system, due to the way alarmModelSpecificPointer works. If someone defined a DMTF-ALARM-MIB, it could not under your reasoning exist in a system that also supported the ITU alarm stuff. Randy From disman-admin@ietf.org Fri Oct 10 23:59:28 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 XAA06853 for ; Fri, 10 Oct 2003 23:59:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8AuE-0001ig-Ok; Fri, 10 Oct 2003 23:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Ats-0001iM-5B for disman@optimus.ietf.org; Fri, 10 Oct 2003 23:58:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06844 for ; Fri, 10 Oct 2003 23:58:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8Ato-0007K2-00 for disman@ietf.org; Fri, 10 Oct 2003 23:58:36 -0400 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1A8Ato-0007Jz-00 for disman@ietf.org; Fri, 10 Oct 2003 23:58:36 -0400 Received: from h-68-164-27-209.snvacaid.dynamic.covad.net ([68.164.27.209] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A8Ato-0003hr-00 for disman@ietf.org; Fri, 10 Oct 2003 20:58:36 -0700 Message-ID: <008201c38fab$fdbce320$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408DFA554@zcard0ka.ca.nortel.com> Subject: Re: [Disman] LocalSnmpEngineOrZeroLenStr in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 20:58:54 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Friday, October 10, 2003 12:44 PM > Subject: RE: [Disman] LocalSnmpEngineOrZeroLenStr in draft-ietf-disman-alarm-mib-15.txt ... > I don't get your issue with the word instantiate > (http://dictionary.reference.com/search?r=2&q=instantiate). Textual > conventions are abstract. When we use them in object definitions they are > concrete. It talks about "instantiation of this object". In a TC definition, what could "this object" possibly refer to? Again, in all the cases where the TC is used, the conditions for zero length are the same, so why not simply factor that commonality back into the TC definition, and get rid of the indirection? > The 'Local' refers to where the alarm originated. So on a distributed > manager, there could potentially be different engine IDs. This is explained > in the instantiation of the TC. But as these are presently written, it sounds like the value has to be zero-length string until it has received things with different engineIDs. I'm sure that's not what's intended. > Sharon > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Thursday, October 02, 2003 11:18 PM > To: Disman (E-mail) > Subject: [Disman] LocalSnmpEngineOrZeroLenStr in > 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 > ... > > 44) page 15 (LocalSnmpEngineOrZeroLenStr): where the DESCRIPTION > > talks about "instantiation" doesn't make sense. I think it's > > referring to use of the TC in an OBJECT-TYPE definition, rather > > than object instantiation. > > > > Sharon -> This seems more a wordsmith thing. > ... > > The DESCRIPTION still doesn't make sense. It currently says: > "An SNMP Engine ID or a zero-length string. The > instantiation of this object will provide guidance > on when this will be an SNMP Engine ID and when it > will be a zero lengths string" > > This is a TC definition, so "instantiation of this object will provide > guidance" makes no sense at all to me. In both cases where this TC is used, > the conditions for a zero-length string value are the same: either the > notification came from a protocol (SNMPv1 is not the only one! don't forget > SNMPv2c) which doesn't use SNMP Engine ID, or all entries in the table > currently have the same Engine ID. (I guess that means that when one > arrives from some other engine, all these objects' values will change from > zero-length string back to their "real" values. Am I the only person > bothered by this?) > > Randy > > > > From exim@www1.ietf.org Fri Oct 10 23:59:33 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 XAA06876 for ; Fri, 10 Oct 2003 23:59:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8AuM-0001kC-Vf for disman-archive@odin.ietf.org; Fri, 10 Oct 2003 23:59:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9B3xA50006704 for disman-archive@odin.ietf.org; Fri, 10 Oct 2003 23:59:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8AuL-0001jD-2x for disman-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 23:59:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06848 for ; Fri, 10 Oct 2003 23:58:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8AuH-0007K9-00 for disman-web-archive@ietf.org; Fri, 10 Oct 2003 23:59:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8AuG-0007K6-00 for disman-web-archive@ietf.org; Fri, 10 Oct 2003 23:59:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8AuE-0001ig-Ok; Fri, 10 Oct 2003 23:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Ats-0001iM-5B for disman@optimus.ietf.org; Fri, 10 Oct 2003 23:58:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06844 for ; Fri, 10 Oct 2003 23:58:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8Ato-0007K2-00 for disman@ietf.org; Fri, 10 Oct 2003 23:58:36 -0400 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1A8Ato-0007Jz-00 for disman@ietf.org; Fri, 10 Oct 2003 23:58:36 -0400 Received: from h-68-164-27-209.snvacaid.dynamic.covad.net ([68.164.27.209] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A8Ato-0003hr-00 for disman@ietf.org; Fri, 10 Oct 2003 20:58:36 -0700 Message-ID: <008201c38fab$fdbce320$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408DFA554@zcard0ka.ca.nortel.com> Subject: Re: [Disman] LocalSnmpEngineOrZeroLenStr in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 20:58:54 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Friday, October 10, 2003 12:44 PM > Subject: RE: [Disman] LocalSnmpEngineOrZeroLenStr in draft-ietf-disman-alarm-mib-15.txt ... > I don't get your issue with the word instantiate > (http://dictionary.reference.com/search?r=2&q=instantiate). Textual > conventions are abstract. When we use them in object definitions they are > concrete. It talks about "instantiation of this object". In a TC definition, what could "this object" possibly refer to? Again, in all the cases where the TC is used, the conditions for zero length are the same, so why not simply factor that commonality back into the TC definition, and get rid of the indirection? > The 'Local' refers to where the alarm originated. So on a distributed > manager, there could potentially be different engine IDs. This is explained > in the instantiation of the TC. But as these are presently written, it sounds like the value has to be zero-length string until it has received things with different engineIDs. I'm sure that's not what's intended. > Sharon > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Thursday, October 02, 2003 11:18 PM > To: Disman (E-mail) > Subject: [Disman] LocalSnmpEngineOrZeroLenStr in > 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 > ... > > 44) page 15 (LocalSnmpEngineOrZeroLenStr): where the DESCRIPTION > > talks about "instantiation" doesn't make sense. I think it's > > referring to use of the TC in an OBJECT-TYPE definition, rather > > than object instantiation. > > > > Sharon -> This seems more a wordsmith thing. > ... > > The DESCRIPTION still doesn't make sense. It currently says: > "An SNMP Engine ID or a zero-length string. The > instantiation of this object will provide guidance > on when this will be an SNMP Engine ID and when it > will be a zero lengths string" > > This is a TC definition, so "instantiation of this object will provide > guidance" makes no sense at all to me. In both cases where this TC is used, > the conditions for a zero-length string value are the same: either the > notification came from a protocol (SNMPv1 is not the only one! don't forget > SNMPv2c) which doesn't use SNMP Engine ID, or all entries in the table > currently have the same Engine ID. (I guess that means that when one > arrives from some other engine, all these objects' values will change from > zero-length string back to their "real" values. Am I the only person > bothered by this?) > > Randy > > > > From disman-admin@ietf.org Sat Oct 11 00:04:32 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 AAA07014 for ; Sat, 11 Oct 2003 00:04:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Az6-0001vW-JQ; Sat, 11 Oct 2003 00:04:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8AyA-0001ss-Rd for disman@optimus.ietf.org; Sat, 11 Oct 2003 00:03:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06965 for ; Sat, 11 Oct 2003 00:02:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8Ay8-0007LZ-00 for disman@ietf.org; Sat, 11 Oct 2003 00:03:04 -0400 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1A8Ay7-0007LW-00 for disman@ietf.org; Sat, 11 Oct 2003 00:03:03 -0400 Received: from h-68-164-27-209.snvacaid.dynamic.covad.net ([68.164.27.209] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A8Ay7-00013r-00 for disman@ietf.org; Fri, 10 Oct 2003 21:03:03 -0700 Message-ID: <008901c38fac$9ce7f520$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D86F05@zcard0ka.ca.nortel.com> Subject: Re: [Disman] "table wrapping" in alarm MIB -15- 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, 10 Oct 2003 21:03:22 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Friday, October 10, 2003 11:18 AM > Subject: RE: [Disman] "table wrapping" in alarm MIB -15- ... > The following is the proposed resolution to Randy-74-4. Assuming no > objection, this item will is closed with no changes to the draft. > > In the definition of alarmActiveEntry is > " > "Entries appear in this table when alarms are raised. They > are removed when the alarm is cleared." > > One of the indices into this table is DataAndTime object. This table > therefore will not wrap, so discussing what happens when the table wraps > does not make sense. The statement that indicates that entries are removed > when the alarm is cleared implies that entries stay in the table while they > are active. End of story. ... Sorry, it's not. Please re-read my original comment: > > 75-4) I missed anything like an "alarmActiveMaximum", yet the document > > doesn't seem to describe what should happen if there are too many > > active alarms, as might happen if there are lots of instances of a > > particular type of resource, and an administrator inadvertently > > specifies a frequent, innocuous event as being of interest. ... The issue still stands. Randy From exim@www1.ietf.org Sat Oct 11 00:04:41 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 AAA07029 for ; Sat, 11 Oct 2003 00:04:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8AzM-00020o-0g for disman-archive@odin.ietf.org; Sat, 11 Oct 2003 00:04:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9B44JSE007685 for disman-archive@odin.ietf.org; Sat, 11 Oct 2003 00:04:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8AzJ-0001zc-SF for disman-web-archive@optimus.ietf.org; Sat, 11 Oct 2003 00:04:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07005 for ; Sat, 11 Oct 2003 00:04:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8AzB-0007MY-00 for disman-web-archive@ietf.org; Sat, 11 Oct 2003 00:04:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8AzB-0007MV-00 for disman-web-archive@ietf.org; Sat, 11 Oct 2003 00:04:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Az6-0001vW-JQ; Sat, 11 Oct 2003 00:04:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8AyA-0001ss-Rd for disman@optimus.ietf.org; Sat, 11 Oct 2003 00:03:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06965 for ; Sat, 11 Oct 2003 00:02:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8Ay8-0007LZ-00 for disman@ietf.org; Sat, 11 Oct 2003 00:03:04 -0400 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1A8Ay7-0007LW-00 for disman@ietf.org; Sat, 11 Oct 2003 00:03:03 -0400 Received: from h-68-164-27-209.snvacaid.dynamic.covad.net ([68.164.27.209] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A8Ay7-00013r-00 for disman@ietf.org; Fri, 10 Oct 2003 21:03:03 -0700 Message-ID: <008901c38fac$9ce7f520$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408D86F05@zcard0ka.ca.nortel.com> Subject: Re: [Disman] "table wrapping" in alarm MIB -15- 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, 10 Oct 2003 21:03:22 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Friday, October 10, 2003 11:18 AM > Subject: RE: [Disman] "table wrapping" in alarm MIB -15- ... > The following is the proposed resolution to Randy-74-4. Assuming no > objection, this item will is closed with no changes to the draft. > > In the definition of alarmActiveEntry is > " > "Entries appear in this table when alarms are raised. They > are removed when the alarm is cleared." > > One of the indices into this table is DataAndTime object. This table > therefore will not wrap, so discussing what happens when the table wraps > does not make sense. The statement that indicates that entries are removed > when the alarm is cleared implies that entries stay in the table while they > are active. End of story. ... Sorry, it's not. Please re-read my original comment: > > 75-4) I missed anything like an "alarmActiveMaximum", yet the document > > doesn't seem to describe what should happen if there are too many > > active alarms, as might happen if there are lots of instances of a > > particular type of resource, and an administrator inadvertently > > specifies a frequent, innocuous event as being of interest. ... The issue still stands. Randy From disman-admin@ietf.org Tue Oct 14 10:44:29 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 KAA12791 for ; Tue, 14 Oct 2003 10:44:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9QP3-0002Wp-SL; Tue, 14 Oct 2003 10:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9QOb-0002WE-JE for disman@optimus.ietf.org; Tue, 14 Oct 2003 10:43:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12716 for ; Tue, 14 Oct 2003 10:43:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9QOZ-0003WX-00 for disman@ietf.org; Tue, 14 Oct 2003 10:43:31 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A9QOY-0003Uo-00 for disman@ietf.org; Tue, 14 Oct 2003 10:43:30 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9EEgcI03246 for ; Tue, 14 Oct 2003 10:42:38 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S6642RD>; Tue, 14 Oct 2003 10:42:38 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408DFAB74@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm M IB 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, 14 Oct 2003 10:42:31 -0400 Hi Content: " From: IETF Disman Working Group To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 Title: Response to Liaison on Alarm MIB Response Contact: Randy Presuhn Technical Contact: disman@ietf.org Purpose: In Reply to Liaison Thank you for the interest in the Alarm MIB. The latest version is currently completing Area Director Review and can be found at http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt The Distributed Management (disman) working group hopes to advance the current I-D to Proposed Standard, with minimal changes. In the future, if the working group is chartered with an Alarm MIB version 2, we will be interested in cooperating with you to ensure your requirements are considered." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 1:52 PM To: Disman (E-mail) Subject: Re: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm MIB Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 10:41 AM > Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on > Alarm MIB ... > From: IETF Disman Working Group > To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 > Title: Response to Liaison on Alarm MIB > Response Contact: Randy Presuhn > Technical Contact: disman@ietf.org > Purpose: In Replay to Liaison > > Thank you for the interest in the Alarm MIB. The latest version is > currently completed Area Director Review and can be found at "completed" -> "under" > > http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt > > The Distributed Management (disman) working group hopes to advance the > current I-D to Proposed Standard, with minimal editorial changes. In > the It's not clear to me whether "editorial" is too strong. To avoid misleading anyone, let's remove "editorial" or wait til we've finished the review cycle. > future, if the working group is chartered with an Alarm MIB version 2, > we will be interested in cooperating with you to ensure your > requirements are considered." > > 2) Process > Randy said: > > "Let's see how > http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt > works." > > There is discussion about a web page that I can't find. Any Ideas? ... The automation the i-d talks about isn't in place, as far as I know, but it wouldn't hurt to ask the i-d authors. My intent was that we try to follow the workflow outlined there, so that all the right people are involved in the right sequence, and so that we can provide the i-d authors with useful feedback. Randy From exim@www1.ietf.org Tue Oct 14 10:44: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 KAA12806 for ; Tue, 14 Oct 2003 10:44:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9QPC-0002Xh-Ih for disman-archive@odin.ietf.org; Tue, 14 Oct 2003 10:44:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EEiAcJ009767 for disman-archive@odin.ietf.org; Tue, 14 Oct 2003 10:44:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9QPC-0002XS-Eo for disman-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 10:44:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12771 for ; Tue, 14 Oct 2003 10:43:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9QPA-0003YQ-00 for disman-web-archive@ietf.org; Tue, 14 Oct 2003 10:44:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9QP9-0003YM-00 for disman-web-archive@ietf.org; Tue, 14 Oct 2003 10:44:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9QP3-0002Wp-SL; Tue, 14 Oct 2003 10:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9QOb-0002WE-JE for disman@optimus.ietf.org; Tue, 14 Oct 2003 10:43:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12716 for ; Tue, 14 Oct 2003 10:43:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9QOZ-0003WX-00 for disman@ietf.org; Tue, 14 Oct 2003 10:43:31 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A9QOY-0003Uo-00 for disman@ietf.org; Tue, 14 Oct 2003 10:43:30 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9EEgcI03246 for ; Tue, 14 Oct 2003 10:42:38 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S6642RD>; Tue, 14 Oct 2003 10:42:38 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408DFAB74@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm M IB 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, 14 Oct 2003 10:42:31 -0400 Hi Content: " From: IETF Disman Working Group To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 Title: Response to Liaison on Alarm MIB Response Contact: Randy Presuhn Technical Contact: disman@ietf.org Purpose: In Reply to Liaison Thank you for the interest in the Alarm MIB. The latest version is currently completing Area Director Review and can be found at http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt The Distributed Management (disman) working group hopes to advance the current I-D to Proposed Standard, with minimal changes. In the future, if the working group is chartered with an Alarm MIB version 2, we will be interested in cooperating with you to ensure your requirements are considered." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 1:52 PM To: Disman (E-mail) Subject: Re: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm MIB Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 10:41 AM > Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on > Alarm MIB ... > From: IETF Disman Working Group > To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 > Title: Response to Liaison on Alarm MIB > Response Contact: Randy Presuhn > Technical Contact: disman@ietf.org > Purpose: In Replay to Liaison > > Thank you for the interest in the Alarm MIB. The latest version is > currently completed Area Director Review and can be found at "completed" -> "under" > > http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt > > The Distributed Management (disman) working group hopes to advance the > current I-D to Proposed Standard, with minimal editorial changes. In > the It's not clear to me whether "editorial" is too strong. To avoid misleading anyone, let's remove "editorial" or wait til we've finished the review cycle. > future, if the working group is chartered with an Alarm MIB version 2, > we will be interested in cooperating with you to ensure your > requirements are considered." > > 2) Process > Randy said: > > "Let's see how > http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt > works." > > There is discussion about a web page that I can't find. Any Ideas? ... The automation the i-d talks about isn't in place, as far as I know, but it wouldn't hurt to ask the i-d authors. My intent was that we try to follow the workflow outlined there, so that all the right people are involved in the right sequence, and so that we can provide the i-d authors with useful feedback. Randy From disman-admin@ietf.org Tue Oct 14 11:49: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 LAA15805 for ; Tue, 14 Oct 2003 11:49:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RPx-0006mz-Cu; Tue, 14 Oct 2003 11:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ROz-0006jv-CI for disman@optimus.ietf.org; Tue, 14 Oct 2003 11:48:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15730 for ; Tue, 14 Oct 2003 11:47:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9ROy-0004PK-00 for disman@ietf.org; Tue, 14 Oct 2003 11:48:00 -0400 Received: from conure.mail.pas.earthlink.net ([207.217.120.54]) by ietf-mx with esmtp (Exim 4.12) id 1A9ROx-0004PF-00 for disman@ietf.org; Tue, 14 Oct 2003 11:47:59 -0400 Received: from h-68-164-24-178.snvacaid.dynamic.covad.net ([68.164.24.178] helo=oemcomputer) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A9ROv-0004hl-00 for disman@ietf.org; Tue, 14 Oct 2003 08:47:57 -0700 Message-ID: <002a01c3926a$99a01620$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408DFAB74@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm MIB X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Oct 2003 08:48:21 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Tuesday, October 14, 2003 7:42 AM > Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm MIB ... > " > From: IETF Disman Working Group > To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 > Title: Response to Liaison on Alarm MIB > Response Contact: Randy Presuhn > Technical Contact: disman@ietf.org > Purpose: In Reply to Liaison > > Thank you for the interest in the Alarm MIB. The latest version is currently > completing Area Director Review and can be found at > > http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt > > The Distributed Management (disman) working group hopes to advance the > current I-D to Proposed Standard, with minimal changes. In the future, if > the working group is chartered with an Alarm MIB version 2, we will be > interested in cooperating with you to ensure your requirements are > considered." ... Looks good to me. Is everone else happy with it? The ITU folk have been a great resource, and I'd like to maintain the relationship. Randy From exim@www1.ietf.org Tue Oct 14 11:49:28 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 LAA15820 for ; Tue, 14 Oct 2003 11:49:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RQ3-0006oe-Sa for disman-archive@odin.ietf.org; Tue, 14 Oct 2003 11:49:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EFn731026194 for disman-archive@odin.ietf.org; Tue, 14 Oct 2003 11:49:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RQ3-0006oP-NR for disman-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 11:49:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15789 for ; Tue, 14 Oct 2003 11:48:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9RQ2-0004QD-00 for disman-web-archive@ietf.org; Tue, 14 Oct 2003 11:49:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9RQ2-0004QA-00 for disman-web-archive@ietf.org; Tue, 14 Oct 2003 11:49:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RPx-0006mz-Cu; Tue, 14 Oct 2003 11:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ROz-0006jv-CI for disman@optimus.ietf.org; Tue, 14 Oct 2003 11:48:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15730 for ; Tue, 14 Oct 2003 11:47:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9ROy-0004PK-00 for disman@ietf.org; Tue, 14 Oct 2003 11:48:00 -0400 Received: from conure.mail.pas.earthlink.net ([207.217.120.54]) by ietf-mx with esmtp (Exim 4.12) id 1A9ROx-0004PF-00 for disman@ietf.org; Tue, 14 Oct 2003 11:47:59 -0400 Received: from h-68-164-24-178.snvacaid.dynamic.covad.net ([68.164.24.178] helo=oemcomputer) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A9ROv-0004hl-00 for disman@ietf.org; Tue, 14 Oct 2003 08:47:57 -0700 Message-ID: <002a01c3926a$99a01620$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408DFAB74@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm MIB X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Oct 2003 08:48:21 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Tuesday, October 14, 2003 7:42 AM > Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm MIB ... > " > From: IETF Disman Working Group > To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 > Title: Response to Liaison on Alarm MIB > Response Contact: Randy Presuhn > Technical Contact: disman@ietf.org > Purpose: In Reply to Liaison > > Thank you for the interest in the Alarm MIB. The latest version is currently > completing Area Director Review and can be found at > > http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt > > The Distributed Management (disman) working group hopes to advance the > current I-D to Proposed Standard, with minimal changes. In the future, if > the working group is chartered with an Alarm MIB version 2, we will be > interested in cooperating with you to ensure your requirements are > considered." ... Looks good to me. Is everone else happy with it? The ITU folk have been a great resource, and I'd like to maintain the relationship. Randy From disman-admin@ietf.org Tue Oct 14 12:06:22 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 MAA17146 for ; Tue, 14 Oct 2003 12:06:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RgP-0007zA-KD; Tue, 14 Oct 2003 12:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RgN-0007w5-1Q for disman@optimus.ietf.org; Tue, 14 Oct 2003 12:05:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17113 for ; Tue, 14 Oct 2003 12:05:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9RgL-0004ks-00 for disman@ietf.org; Tue, 14 Oct 2003 12:05:57 -0400 Received: from conure.mail.pas.earthlink.net ([207.217.120.54]) by ietf-mx with esmtp (Exim 4.12) id 1A9RgL-0004kk-00 for disman@ietf.org; Tue, 14 Oct 2003 12:05:57 -0400 Received: from h-68-164-24-178.snvacaid.dynamic.covad.net ([68.164.24.178] helo=oemcomputer) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A9RgG-0003Gj-00 for disman@ietf.org; Tue, 14 Oct 2003 09:05:52 -0700 Message-ID: <003401c3926d$1a693960$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] Disman session in Minneapolis, MN, USA? 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, 14 Oct 2003 09:06:18 -0700 Hi - Is there any reason the disman WG would need to meet in Minneapolis? I already plan to attend the IETF meeting, but need to know whether to reserve WG session time. Randy > From: "Internet-Drafts Administrator" > To: > Sent: Tuesday, October 14, 2003 7:15 AM > Subject: Internet-Draft Cutoff Dates for Minneapolis, MN, USA > > NOTE: There are two (2) Internet-Draft Cutoff dates. > > October 20th: Cutoff for Initial Submissions (new documents). > > All initial submissions(-00) must be submitted by Monday, October 20th, > at 09:00 ET. Initial submissions received after this time will NOT be > made available in the Internet-Drafts directory, and will have to be > resubmitted. > > As before, all initial submissions (-00.txt) with a filename beginning > with a draft-ietf MUST be approved by the appropriate WG Chair prior to > processing and announcing. WG Chair approval must be received by > Wednesday, October 15th. > > Please do NOT wait until the last minute to submit. > > Be advised: NO placeholders. Updates to initial submissions received > the week of October 20th will NOT be accepted. > > October 27th: FINAL Internet-Draft Cutoff > > All revised Internet-Draft submissions must be submitted by Monday, > October 27th, 2003 at 09:00 ET. Internet-Drafts received after this > time will NOT be announced NOR made available in the Internet-Drafts > Directories. > > We will begin accepting Internet-Draft submissions starting Monday, > November 10th. > > Thank you for your understanding and cooperation. Please do not hesitate > to contact us if you have any questions or concerns. > > FYI: These and other significant dates can be found at > http://www.ietf.org/meetings/cutoff_dates_58.html > > > > > From exim@www1.ietf.org Tue Oct 14 12:06: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 MAA17161 for ; Tue, 14 Oct 2003 12:06:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RgR-0007zq-5n for disman-archive@odin.ietf.org; Tue, 14 Oct 2003 12:06:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EG63tW030738 for disman-archive@odin.ietf.org; Tue, 14 Oct 2003 12:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RgQ-0007zh-UM for disman-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 12:06:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17122 for ; Tue, 14 Oct 2003 12:05:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9RgP-0004l4-00 for disman-web-archive@ietf.org; Tue, 14 Oct 2003 12:06:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9RgP-0004l1-00 for disman-web-archive@ietf.org; Tue, 14 Oct 2003 12:06:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RgP-0007zA-KD; Tue, 14 Oct 2003 12:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RgN-0007w5-1Q for disman@optimus.ietf.org; Tue, 14 Oct 2003 12:05:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17113 for ; Tue, 14 Oct 2003 12:05:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9RgL-0004ks-00 for disman@ietf.org; Tue, 14 Oct 2003 12:05:57 -0400 Received: from conure.mail.pas.earthlink.net ([207.217.120.54]) by ietf-mx with esmtp (Exim 4.12) id 1A9RgL-0004kk-00 for disman@ietf.org; Tue, 14 Oct 2003 12:05:57 -0400 Received: from h-68-164-24-178.snvacaid.dynamic.covad.net ([68.164.24.178] helo=oemcomputer) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A9RgG-0003Gj-00 for disman@ietf.org; Tue, 14 Oct 2003 09:05:52 -0700 Message-ID: <003401c3926d$1a693960$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] Disman session in Minneapolis, MN, USA? 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, 14 Oct 2003 09:06:18 -0700 Hi - Is there any reason the disman WG would need to meet in Minneapolis? I already plan to attend the IETF meeting, but need to know whether to reserve WG session time. Randy > From: "Internet-Drafts Administrator" > To: > Sent: Tuesday, October 14, 2003 7:15 AM > Subject: Internet-Draft Cutoff Dates for Minneapolis, MN, USA > > NOTE: There are two (2) Internet-Draft Cutoff dates. > > October 20th: Cutoff for Initial Submissions (new documents). > > All initial submissions(-00) must be submitted by Monday, October 20th, > at 09:00 ET. Initial submissions received after this time will NOT be > made available in the Internet-Drafts directory, and will have to be > resubmitted. > > As before, all initial submissions (-00.txt) with a filename beginning > with a draft-ietf MUST be approved by the appropriate WG Chair prior to > processing and announcing. WG Chair approval must be received by > Wednesday, October 15th. > > Please do NOT wait until the last minute to submit. > > Be advised: NO placeholders. Updates to initial submissions received > the week of October 20th will NOT be accepted. > > October 27th: FINAL Internet-Draft Cutoff > > All revised Internet-Draft submissions must be submitted by Monday, > October 27th, 2003 at 09:00 ET. Internet-Drafts received after this > time will NOT be announced NOR made available in the Internet-Drafts > Directories. > > We will begin accepting Internet-Draft submissions starting Monday, > November 10th. > > Thank you for your understanding and cooperation. Please do not hesitate > to contact us if you have any questions or concerns. > > FYI: These and other significant dates can be found at > http://www.ietf.org/meetings/cutoff_dates_58.html > > > > > From disman-admin@ietf.org Tue Oct 14 12:22: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 MAA17908 for ; Tue, 14 Oct 2003 12:22:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Rvu-0000Pv-0u; Tue, 14 Oct 2003 12:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RvG-0000PO-Ln for disman@optimus.ietf.org; Tue, 14 Oct 2003 12:21:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17867 for ; Tue, 14 Oct 2003 12:21:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9RvE-0004y3-00 for disman@ietf.org; Tue, 14 Oct 2003 12:21:20 -0400 Received: from conure.mail.pas.earthlink.net ([207.217.120.54]) by ietf-mx with esmtp (Exim 4.12) id 1A9RvE-0004y0-00 for disman@ietf.org; Tue, 14 Oct 2003 12:21:20 -0400 Received: from h-68-164-24-178.snvacaid.dynamic.covad.net ([68.164.24.178] helo=oemcomputer) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A9RvC-0004so-00; Tue, 14 Oct 2003 09:21:18 -0700 Message-ID: <003b01c3926f$423e2520$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" Cc: References: <200310141310.59138.david.partain@ericsson.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: alarm MIB question... 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, 14 Oct 2003 09:21:44 -0700 Hi - > From: "David Partain (LM/EAB)" > To: ; > Cc: > Sent: Tuesday, October 14, 2003 4:10 AM > Subject: alarm MIB question... > > Hi, > > Can you remind me of the reasoning behind including > alarmActiveVariableOpaqueVal with a syntax of Opaque? > Its inclusion violates RFC 2578: on page 24, section > 7.1.9, it states: "The Opaque type is provided solely for > backward-compatibility, and shall not be used for newly-defined > object types." Seems pretty clear to me. Perhaps you're > doing so in the name of backward-compatibility? Or are you just > choosing to ignore this for the possibility there are enterprise > MIBs that use Opaque for varbinds they sends in a notification? > > I think the document should clearly state that it violates > the Standard but "we know and here's why". > > Cheers, > > David > > -- > Wireless Access Networks E-mail: David.Partain@ericsson.com > Ericsson Research Tel: +46 13 28 41 44 > P.O. Box 1248 Fax: +46 13 28 75 67 > SE-581 12 Linköping, Sweden http://linlab.ericsson.se/ietf You're quite right, and we went through the same discussion during the IESG review of the Log MIB. Consequently, I agree that a note to the effect of "we know and here's why" would save us some grief. I suggest the following words be added to the end of the DESCRIPTION text for alarmActiveVariableOpaqueVal: Note: although the SMI [RFC2578] forbids the use of Opaque in 'standard' MIB modules, this particular usage is driven by the need to be able to accurately represent any well-formed notification, and justified by the need for backward compatibility. Randy From exim@www1.ietf.org Tue Oct 14 12:22: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 MAA17923 for ; Tue, 14 Oct 2003 12:22:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Rvw-0000Qi-Rj for disman-archive@odin.ietf.org; Tue, 14 Oct 2003 12:22:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EGM413001646 for disman-archive@odin.ietf.org; Tue, 14 Oct 2003 12:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Rvw-0000QT-OO for disman-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 12:22:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17896 for ; Tue, 14 Oct 2003 12:21:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Rvv-0004yL-00 for disman-web-archive@ietf.org; Tue, 14 Oct 2003 12:22:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Rvu-0004yI-00 for disman-web-archive@ietf.org; Tue, 14 Oct 2003 12:22:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Rvu-0000Pv-0u; Tue, 14 Oct 2003 12:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9RvG-0000PO-Ln for disman@optimus.ietf.org; Tue, 14 Oct 2003 12:21:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17867 for ; Tue, 14 Oct 2003 12:21:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9RvE-0004y3-00 for disman@ietf.org; Tue, 14 Oct 2003 12:21:20 -0400 Received: from conure.mail.pas.earthlink.net ([207.217.120.54]) by ietf-mx with esmtp (Exim 4.12) id 1A9RvE-0004y0-00 for disman@ietf.org; Tue, 14 Oct 2003 12:21:20 -0400 Received: from h-68-164-24-178.snvacaid.dynamic.covad.net ([68.164.24.178] helo=oemcomputer) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1A9RvC-0004so-00; Tue, 14 Oct 2003 09:21:18 -0700 Message-ID: <003b01c3926f$423e2520$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" Cc: References: <200310141310.59138.david.partain@ericsson.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: alarm MIB question... 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, 14 Oct 2003 09:21:44 -0700 Hi - > From: "David Partain (LM/EAB)" > To: ; > Cc: > Sent: Tuesday, October 14, 2003 4:10 AM > Subject: alarm MIB question... > > Hi, > > Can you remind me of the reasoning behind including > alarmActiveVariableOpaqueVal with a syntax of Opaque? > Its inclusion violates RFC 2578: on page 24, section > 7.1.9, it states: "The Opaque type is provided solely for > backward-compatibility, and shall not be used for newly-defined > object types." Seems pretty clear to me. Perhaps you're > doing so in the name of backward-compatibility? Or are you just > choosing to ignore this for the possibility there are enterprise > MIBs that use Opaque for varbinds they sends in a notification? > > I think the document should clearly state that it violates > the Standard but "we know and here's why". > > Cheers, > > David > > -- > Wireless Access Networks E-mail: David.Partain@ericsson.com > Ericsson Research Tel: +46 13 28 41 44 > P.O. Box 1248 Fax: +46 13 28 75 67 > SE-581 12 Linköping, Sweden http://linlab.ericsson.se/ietf You're quite right, and we went through the same discussion during the IESG review of the Log MIB. Consequently, I agree that a note to the effect of "we know and here's why" would save us some grief. I suggest the following words be added to the end of the DESCRIPTION text for alarmActiveVariableOpaqueVal: Note: although the SMI [RFC2578] forbids the use of Opaque in 'standard' MIB modules, this particular usage is driven by the need to be able to accurately represent any well-formed notification, and justified by the need for backward compatibility. Randy From disman-admin@ietf.org Tue Oct 14 14:48:29 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 OAA23552 for ; Tue, 14 Oct 2003 14:48:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UDB-000116-6X; Tue, 14 Oct 2003 14:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UDA-00010q-Ct for disman@optimus.ietf.org; Tue, 14 Oct 2003 14:48:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23533 for ; Tue, 14 Oct 2003 14:47:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9UD7-0006WC-00 for disman@ietf.org; Tue, 14 Oct 2003 14:47:57 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A9UD6-0006W0-00 for disman@ietf.org; Tue, 14 Oct 2003 14:47:56 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h9EIlMN06913 for ; Tue, 14 Oct 2003 13:47:22 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3W3A4C>; Tue, 14 Oct 2003 20:47:21 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502B426B5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Randy Presuhn , "Disman (E-mail)" Cc: David.Partain@ericsson.com Subject: RE: [Disman] Re: alarm MIB question... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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, 14 Oct 2003 20:47:11 +0200 > You're quite right, and we went through the same discussion during the > IESG review of the Log MIB. Consequently, I agree that a note to the > effect of "we know and here's why" would save us some grief. I > suggest the following words be added to the end of the DESCRIPTION > text for alarmActiveVariableOpaqueVal: > > Note: although the SMI [RFC2578] forbids the use of Opaque in I'd use (RFC 2578) to avoid a citation in the MIB module itself. Once the MIB gets extracted it points to nowhere. Bert > 'standard' MIB modules, this particular usage is driven by the > need to be able to accurately represent any well-formed notification, > and justified by the need for backward compatibility. > > Randy > > > From exim@www1.ietf.org Tue Oct 14 14:48: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 OAA23567 for ; Tue, 14 Oct 2003 14:48:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UDK-00012y-5k for disman-archive@odin.ietf.org; Tue, 14 Oct 2003 14:48:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EImAjh004018 for disman-archive@odin.ietf.org; Tue, 14 Oct 2003 14:48:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UDK-00012j-1K for disman-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 14:48:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23544 for ; Tue, 14 Oct 2003 14:47:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9UDH-0006WT-00 for disman-web-archive@ietf.org; Tue, 14 Oct 2003 14:48:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9UDG-0006WQ-00 for disman-web-archive@ietf.org; Tue, 14 Oct 2003 14:48:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UDB-000116-6X; Tue, 14 Oct 2003 14:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UDA-00010q-Ct for disman@optimus.ietf.org; Tue, 14 Oct 2003 14:48:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23533 for ; Tue, 14 Oct 2003 14:47:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9UD7-0006WC-00 for disman@ietf.org; Tue, 14 Oct 2003 14:47:57 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A9UD6-0006W0-00 for disman@ietf.org; Tue, 14 Oct 2003 14:47:56 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h9EIlMN06913 for ; Tue, 14 Oct 2003 13:47:22 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3W3A4C>; Tue, 14 Oct 2003 20:47:21 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502B426B5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Randy Presuhn , "Disman (E-mail)" Cc: David.Partain@ericsson.com Subject: RE: [Disman] Re: alarm MIB question... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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, 14 Oct 2003 20:47:11 +0200 > You're quite right, and we went through the same discussion during the > IESG review of the Log MIB. Consequently, I agree that a note to the > effect of "we know and here's why" would save us some grief. I > suggest the following words be added to the end of the DESCRIPTION > text for alarmActiveVariableOpaqueVal: > > Note: although the SMI [RFC2578] forbids the use of Opaque in I'd use (RFC 2578) to avoid a citation in the MIB module itself. Once the MIB gets extracted it points to nowhere. Bert > 'standard' MIB modules, this particular usage is driven by the > need to be able to accurately represent any well-formed notification, > and justified by the need for backward compatibility. > > Randy > > > From disman-admin@ietf.org Tue Oct 14 14:49: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 OAA23592 for ; Tue, 14 Oct 2003 14:49:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UE8-00014p-OK; Tue, 14 Oct 2003 14:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UDA-00010r-EJ for disman@optimus.ietf.org; Tue, 14 Oct 2003 14:48:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23534 for ; Tue, 14 Oct 2003 14:47:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9UD7-0006WF-00 for disman@ietf.org; Tue, 14 Oct 2003 14:47:57 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A9UD6-0006Vz-00 for disman@ietf.org; Tue, 14 Oct 2003 14:47:56 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h9EIlMY06646 for ; Tue, 14 Oct 2003 13:47:23 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3W3A4A>; Tue, 14 Oct 2003 20:47:21 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502B426B4@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Randy Presuhn , "Disman (E-mail)" Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm M IB MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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, 14 Oct 2003 20:47:11 +0200 Ship it! Thanks, Bert > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: dinsdag 14 oktober 2003 17:48 > To: Disman (E-mail) > Subject: Re: [Disman] Draft Response to Liaison from ITU-T SG > 4 on Alarm > MIB > > > Hi - > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Tuesday, October 14, 2003 7:42 AM > > Subject: RE: [Disman] Draft Response to Liaison from ITU-T > SG 4 on Alarm MIB > ... > > " > > From: IETF Disman Working Group > > To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 > > Title: Response to Liaison on Alarm MIB > > Response Contact: Randy Presuhn > > Technical Contact: disman@ietf.org > > Purpose: In Reply to Liaison > > > > Thank you for the interest in the Alarm MIB. The latest > version is currently > > completing Area Director Review and can be found at > > > > > http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt > > > > The Distributed Management (disman) working group hopes to > advance the > > current I-D to Proposed Standard, with minimal changes. In > the future, if > > the working group is chartered with an Alarm MIB version 2, > we will be > > interested in cooperating with you to ensure your requirements are > > considered." > ... > > Looks good to me. Is everone else happy with it? The ITU > folk have been > a great resource, and I'd like to maintain the relationship. > > Randy > > > From exim@www1.ietf.org Tue Oct 14 14:49:22 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 OAA23607 for ; Tue, 14 Oct 2003 14:49:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UE9-00017h-Vv for disman-archive@odin.ietf.org; Tue, 14 Oct 2003 14:49:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EIn1Qf004311 for disman-archive@odin.ietf.org; Tue, 14 Oct 2003 14:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UE9-00017S-Od for disman-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 14:49:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23584 for ; Tue, 14 Oct 2003 14:48:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9UE6-0006We-00 for disman-web-archive@ietf.org; Tue, 14 Oct 2003 14:48:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9UE6-0006Wb-00 for disman-web-archive@ietf.org; Tue, 14 Oct 2003 14:48:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UE8-00014p-OK; Tue, 14 Oct 2003 14:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UDA-00010r-EJ for disman@optimus.ietf.org; Tue, 14 Oct 2003 14:48:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23534 for ; Tue, 14 Oct 2003 14:47:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9UD7-0006WF-00 for disman@ietf.org; Tue, 14 Oct 2003 14:47:57 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A9UD6-0006Vz-00 for disman@ietf.org; Tue, 14 Oct 2003 14:47:56 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h9EIlMY06646 for ; Tue, 14 Oct 2003 13:47:23 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3W3A4A>; Tue, 14 Oct 2003 20:47:21 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502B426B4@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Randy Presuhn , "Disman (E-mail)" Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm M IB MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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, 14 Oct 2003 20:47:11 +0200 Ship it! Thanks, Bert > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: dinsdag 14 oktober 2003 17:48 > To: Disman (E-mail) > Subject: Re: [Disman] Draft Response to Liaison from ITU-T SG > 4 on Alarm > MIB > > > Hi - > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Tuesday, October 14, 2003 7:42 AM > > Subject: RE: [Disman] Draft Response to Liaison from ITU-T > SG 4 on Alarm MIB > ... > > " > > From: IETF Disman Working Group > > To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 > > Title: Response to Liaison on Alarm MIB > > Response Contact: Randy Presuhn > > Technical Contact: disman@ietf.org > > Purpose: In Reply to Liaison > > > > Thank you for the interest in the Alarm MIB. The latest > version is currently > > completing Area Director Review and can be found at > > > > > http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt > > > > The Distributed Management (disman) working group hopes to > advance the > > current I-D to Proposed Standard, with minimal changes. In > the future, if > > the working group is chartered with an Alarm MIB version 2, > we will be > > interested in cooperating with you to ensure your requirements are > > considered." > ... > > Looks good to me. Is everone else happy with it? The ITU > folk have been > a great resource, and I'd like to maintain the relationship. > > Randy > > > From disman-admin@ietf.org Wed Oct 15 07:57:34 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 HAA25943 for ; Wed, 15 Oct 2003 07:57:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kH0-0000bs-8v; Wed, 15 Oct 2003 07:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kGf-0000aG-43 for disman@optimus.ietf.org; Wed, 15 Oct 2003 07:56:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25898 for ; Wed, 15 Oct 2003 07:56:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9kGe-0003Nq-00 for disman@ietf.org; Wed, 15 Oct 2003 07:56:40 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A9kGd-0003NZ-00 for disman@ietf.org; Wed, 15 Oct 2003 07:56:39 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h9FBu5808067 for ; Wed, 15 Oct 2003 06:56:05 -0500 (CDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id ; Wed, 15 Oct 2003 07:56:04 -0400 Message-ID: From: "Lam, Hing-Kam (Kam)" To: Randy Presuhn , "Disman (E-mail)" Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm M IB MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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, 15 Oct 2003 07:56:03 -0400 Sharon, As suggested by Chair before, you may want to mention the approval of ARC-MIB, which models the M.3100 Amd.3 Alarm Reporting Control function and also provide the links for draft-ietf-disman-conditionmib-10.txt. Regards, Kam > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Tuesday, October 14, 2003 11:48 AM > To: Disman (E-mail) > Subject: Re: [Disman] Draft Response to Liaison from ITU-T SG > 4 on Alarm > MIB > > > Hi - > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Tuesday, October 14, 2003 7:42 AM > > Subject: RE: [Disman] Draft Response to Liaison from ITU-T > SG 4 on Alarm MIB > ... > > " > > From: IETF Disman Working Group > > To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 > > Title: Response to Liaison on Alarm MIB > > Response Contact: Randy Presuhn > > Technical Contact: disman@ietf.org > > Purpose: In Reply to Liaison > > > > Thank you for the interest in the Alarm MIB. The latest > version is currently > > completing Area Director Review and can be found at > > > > > http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt > > > > The Distributed Management (disman) working group hopes to > advance the > > current I-D to Proposed Standard, with minimal changes. In > the future, if > > the working group is chartered with an Alarm MIB version 2, > we will be > > interested in cooperating with you to ensure your requirements are > > considered." > ... > > Looks good to me. Is everone else happy with it? The ITU > folk have been > a great resource, and I'd like to maintain the relationship. > > Randy > > > From exim@www1.ietf.org Wed Oct 15 07:57:37 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 HAA25958 for ; Wed, 15 Oct 2003 07:57:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kHA-0000lg-Ly for disman-archive@odin.ietf.org; Wed, 15 Oct 2003 07:57:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FBvCOV002948 for disman-archive@odin.ietf.org; Wed, 15 Oct 2003 07:57:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kHA-0000lT-Gt for disman-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 07:57:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25924 for ; Wed, 15 Oct 2003 07:57:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9kH9-0003OY-00 for disman-web-archive@ietf.org; Wed, 15 Oct 2003 07:57:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9kH9-0003OV-00 for disman-web-archive@ietf.org; Wed, 15 Oct 2003 07:57:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kH0-0000bs-8v; Wed, 15 Oct 2003 07:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kGf-0000aG-43 for disman@optimus.ietf.org; Wed, 15 Oct 2003 07:56:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25898 for ; Wed, 15 Oct 2003 07:56:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9kGe-0003Nq-00 for disman@ietf.org; Wed, 15 Oct 2003 07:56:40 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A9kGd-0003NZ-00 for disman@ietf.org; Wed, 15 Oct 2003 07:56:39 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h9FBu5808067 for ; Wed, 15 Oct 2003 06:56:05 -0500 (CDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id ; Wed, 15 Oct 2003 07:56:04 -0400 Message-ID: From: "Lam, Hing-Kam (Kam)" To: Randy Presuhn , "Disman (E-mail)" Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm M IB MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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, 15 Oct 2003 07:56:03 -0400 Sharon, As suggested by Chair before, you may want to mention the approval of ARC-MIB, which models the M.3100 Amd.3 Alarm Reporting Control function and also provide the links for draft-ietf-disman-conditionmib-10.txt. Regards, Kam > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Tuesday, October 14, 2003 11:48 AM > To: Disman (E-mail) > Subject: Re: [Disman] Draft Response to Liaison from ITU-T SG > 4 on Alarm > MIB > > > Hi - > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Tuesday, October 14, 2003 7:42 AM > > Subject: RE: [Disman] Draft Response to Liaison from ITU-T > SG 4 on Alarm MIB > ... > > " > > From: IETF Disman Working Group > > To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 > > Title: Response to Liaison on Alarm MIB > > Response Contact: Randy Presuhn > > Technical Contact: disman@ietf.org > > Purpose: In Reply to Liaison > > > > Thank you for the interest in the Alarm MIB. The latest > version is currently > > completing Area Director Review and can be found at > > > > > http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt > > > > The Distributed Management (disman) working group hopes to > advance the > > current I-D to Proposed Standard, with minimal changes. In > the future, if > > the working group is chartered with an Alarm MIB version 2, > we will be > > interested in cooperating with you to ensure your requirements are > > considered." > ... > > Looks good to me. Is everone else happy with it? The ITU > folk have been > a great resource, and I'd like to maintain the relationship. > > Randy > > > From disman-admin@ietf.org Wed Oct 15 08:26: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 IAA26901 for ; Wed, 15 Oct 2003 08:26:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kj4-0002KV-HD; Wed, 15 Oct 2003 08:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kiX-0002Jc-Gl for disman@optimus.ietf.org; Wed, 15 Oct 2003 08:25:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26868 for ; Wed, 15 Oct 2003 08:25:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9kiW-0003l2-00 for disman@ietf.org; Wed, 15 Oct 2003 08:25:28 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A9kiV-0003kf-00 for disman@ietf.org; Wed, 15 Oct 2003 08:25:27 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9FCOoF00267 for ; Wed, 15 Oct 2003 08:24:50 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S664YBF>; Wed, 15 Oct 2003 08:24:50 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408DFB22C@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm M IB 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, 15 Oct 2003 08:24:49 -0400 Hi This is a reply to a specific liaison about the alarm mib. I'd suggest a separate liaison about the ARC MIB be sent if we think there is value in doing do. Sharon -----Original Message----- From: Lam, Hing-Kam (Kam) [mailto:hklam@lucent.com] Sent: Wednesday, October 15, 2003 7:56 AM To: Randy Presuhn; Disman (E-mail) Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm M IB Sharon, As suggested by Chair before, you may want to mention the approval of ARC-MIB, which models the M.3100 Amd.3 Alarm Reporting Control function and also provide the links for draft-ietf-disman-conditionmib-10.txt. Regards, Kam > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Tuesday, October 14, 2003 11:48 AM > To: Disman (E-mail) > Subject: Re: [Disman] Draft Response to Liaison from ITU-T SG > 4 on Alarm > MIB > > > Hi - > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Tuesday, October 14, 2003 7:42 AM > > Subject: RE: [Disman] Draft Response to Liaison from ITU-T > SG 4 on Alarm MIB > ... > > " > > From: IETF Disman Working Group > > To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 > > Title: Response to Liaison on Alarm MIB > > Response Contact: Randy Presuhn > > Technical Contact: disman@ietf.org > > Purpose: In Reply to Liaison > > > > Thank you for the interest in the Alarm MIB. The latest > version is currently > > completing Area Director Review and can be found at > > > > > http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt > > > > The Distributed Management (disman) working group hopes to > advance the > > current I-D to Proposed Standard, with minimal changes. In > the future, if > > the working group is chartered with an Alarm MIB version 2, > we will be > > interested in cooperating with you to ensure your requirements are > > considered." > ... > > Looks good to me. Is everone else happy with it? The ITU > folk have been > a great resource, and I'd like to maintain the relationship. > > Randy > > > From exim@www1.ietf.org Wed Oct 15 08:26: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 IAA26916 for ; Wed, 15 Oct 2003 08:26:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kj6-0002LE-ST for disman-archive@odin.ietf.org; Wed, 15 Oct 2003 08:26:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FCQ4pE008997 for disman-archive@odin.ietf.org; Wed, 15 Oct 2003 08:26:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kj6-0002L2-Mv for disman-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 08:26:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26878 for ; Wed, 15 Oct 2003 08:25:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9kj5-0003lF-00 for disman-web-archive@ietf.org; Wed, 15 Oct 2003 08:26:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9kj5-0003lC-00 for disman-web-archive@ietf.org; Wed, 15 Oct 2003 08:26:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kj4-0002KV-HD; Wed, 15 Oct 2003 08:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kiX-0002Jc-Gl for disman@optimus.ietf.org; Wed, 15 Oct 2003 08:25:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26868 for ; Wed, 15 Oct 2003 08:25:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9kiW-0003l2-00 for disman@ietf.org; Wed, 15 Oct 2003 08:25:28 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A9kiV-0003kf-00 for disman@ietf.org; Wed, 15 Oct 2003 08:25:27 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9FCOoF00267 for ; Wed, 15 Oct 2003 08:24:50 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S664YBF>; Wed, 15 Oct 2003 08:24:50 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408DFB22C@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm M IB 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, 15 Oct 2003 08:24:49 -0400 Hi This is a reply to a specific liaison about the alarm mib. I'd suggest a separate liaison about the ARC MIB be sent if we think there is value in doing do. Sharon -----Original Message----- From: Lam, Hing-Kam (Kam) [mailto:hklam@lucent.com] Sent: Wednesday, October 15, 2003 7:56 AM To: Randy Presuhn; Disman (E-mail) Subject: RE: [Disman] Draft Response to Liaison from ITU-T SG 4 on Alarm M IB Sharon, As suggested by Chair before, you may want to mention the approval of ARC-MIB, which models the M.3100 Amd.3 Alarm Reporting Control function and also provide the links for draft-ietf-disman-conditionmib-10.txt. Regards, Kam > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Tuesday, October 14, 2003 11:48 AM > To: Disman (E-mail) > Subject: Re: [Disman] Draft Response to Liaison from ITU-T SG > 4 on Alarm > MIB > > > Hi - > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Tuesday, October 14, 2003 7:42 AM > > Subject: RE: [Disman] Draft Response to Liaison from ITU-T > SG 4 on Alarm MIB > ... > > " > > From: IETF Disman Working Group > > To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 > > Title: Response to Liaison on Alarm MIB > > Response Contact: Randy Presuhn > > Technical Contact: disman@ietf.org > > Purpose: In Reply to Liaison > > > > Thank you for the interest in the Alarm MIB. The latest > version is currently > > completing Area Director Review and can be found at > > > > > http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt > > > > The Distributed Management (disman) working group hopes to > advance the > > current I-D to Proposed Standard, with minimal changes. In > the future, if > > the working group is chartered with an Alarm MIB version 2, > we will be > > interested in cooperating with you to ensure your requirements are > > considered." > ... > > Looks good to me. Is everone else happy with it? The ITU > folk have been > a great resource, and I'd like to maintain the relationship. > > Randy > > > From disman-admin@ietf.org Wed Oct 15 12:38:33 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 MAA08323 for ; Wed, 15 Oct 2003 12:38:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9oev-0002vz-GF; Wed, 15 Oct 2003 12:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9oeE-0002jG-Jb for disman@optimus.ietf.org; Wed, 15 Oct 2003 12:37:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08252 for ; Wed, 15 Oct 2003 12:37:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9oeC-00079O-00 for disman@ietf.org; Wed, 15 Oct 2003 12:37:16 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A9oeB-000791-00 for disman@ietf.org; Wed, 15 Oct 2003 12:37:15 -0400 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 h9FGabM12022 for ; Wed, 15 Oct 2003 12:36:38 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S6640JQ>; Wed, 15 Oct 2003 12:36:38 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408E99FA7@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, 15 Oct 2003 12:36:37 -0400 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 Oct 15 12:38:35 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 MAA08338 for ; Wed, 15 Oct 2003 12:38:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9of7-0002x5-NF for disman-archive@odin.ietf.org; Wed, 15 Oct 2003 12:38:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FGcDnh011341 for disman-archive@odin.ietf.org; Wed, 15 Oct 2003 12:38:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9of7-0002wq-JG for disman-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 12:38:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08303 for ; Wed, 15 Oct 2003 12:38:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9of5-0007AF-00 for disman-web-archive@ietf.org; Wed, 15 Oct 2003 12:38:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9of5-0007AB-00 for disman-web-archive@ietf.org; Wed, 15 Oct 2003 12:38:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9oev-0002vz-GF; Wed, 15 Oct 2003 12:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9oeE-0002jG-Jb for disman@optimus.ietf.org; Wed, 15 Oct 2003 12:37:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08252 for ; Wed, 15 Oct 2003 12:37:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9oeC-00079O-00 for disman@ietf.org; Wed, 15 Oct 2003 12:37:16 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A9oeB-000791-00 for disman@ietf.org; Wed, 15 Oct 2003 12:37:15 -0400 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 h9FGabM12022 for ; Wed, 15 Oct 2003 12:36:38 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S6640JQ>; Wed, 15 Oct 2003 12:36:38 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408E99FA7@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, 15 Oct 2003 12:36:37 -0400 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 Wed Oct 15 12:58: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 MAA09194 for ; Wed, 15 Oct 2003 12:58:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9oyG-0004Jb-IZ; Wed, 15 Oct 2003 12:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9oxW-0004J2-UP for disman@optimus.ietf.org; Wed, 15 Oct 2003 12:57:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09141 for ; Wed, 15 Oct 2003 12:57:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9oxU-0007Qt-00 for disman@ietf.org; Wed, 15 Oct 2003 12:57:12 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A9oxT-0007QL-00 for disman@ietf.org; Wed, 15 Oct 2003 12:57:12 -0400 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 h9FGudM14031 for ; Wed, 15 Oct 2003 12:56:40 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S6640ZA>; Wed, 15 Oct 2003 12:56:40 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408E99FE9@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: Wed, 15 Oct 2003 12:56:34 -0400 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-write, which allows managers to modify the alarm models to suit their requirements." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 07, 2003 2:48 PM To: Disman (E-mail) Subject: [Disman] Section 4.1.5 in 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 ... > 39) 4.1.5: "table can, and probably should, be" -> > "table MAY be". I don't think we had consensus > to make this a SHOULD, but I'm open to the possibility. ... Proposed change: OLD: 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. NEW: The alarm model table MAY 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. (I have no problems with "SHOULD", but I think "can, and probably should" does not belong in standards-track material.) Randy From exim@www1.ietf.org Wed Oct 15 12:58:29 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 MAA09213 for ; Wed, 15 Oct 2003 12:58:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9oyI-0004LI-7G for disman-archive@odin.ietf.org; Wed, 15 Oct 2003 12:58:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FGw27C016686 for disman-archive@odin.ietf.org; Wed, 15 Oct 2003 12:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9oyI-0004L3-3V for disman-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 12:58:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09184 for ; Wed, 15 Oct 2003 12:57:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9oyG-0007Ru-00 for disman-web-archive@ietf.org; Wed, 15 Oct 2003 12:58:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9oyF-0007Rr-00 for disman-web-archive@ietf.org; Wed, 15 Oct 2003 12:57:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9oyG-0004Jb-IZ; Wed, 15 Oct 2003 12:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9oxW-0004J2-UP for disman@optimus.ietf.org; Wed, 15 Oct 2003 12:57:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09141 for ; Wed, 15 Oct 2003 12:57:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9oxU-0007Qt-00 for disman@ietf.org; Wed, 15 Oct 2003 12:57:12 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A9oxT-0007QL-00 for disman@ietf.org; Wed, 15 Oct 2003 12:57:12 -0400 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 h9FGudM14031 for ; Wed, 15 Oct 2003 12:56:40 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S6640ZA>; Wed, 15 Oct 2003 12:56:40 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408E99FE9@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: Wed, 15 Oct 2003 12:56:34 -0400 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-write, which allows managers to modify the alarm models to suit their requirements." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 07, 2003 2:48 PM To: Disman (E-mail) Subject: [Disman] Section 4.1.5 in 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 ... > 39) 4.1.5: "table can, and probably should, be" -> > "table MAY be". I don't think we had consensus > to make this a SHOULD, but I'm open to the possibility. ... Proposed change: OLD: 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. NEW: The alarm model table MAY 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. (I have no problems with "SHOULD", but I think "can, and probably should" does not belong in standards-track material.) Randy From disman-admin@ietf.org Wed Oct 15 13:04:22 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 NAA09539 for ; Wed, 15 Oct 2003 13:04:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9p45-0004cG-6G; Wed, 15 Oct 2003 13:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9p3W-0004YC-6v for disman@optimus.ietf.org; Wed, 15 Oct 2003 13:03:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09423 for ; Wed, 15 Oct 2003 13:03:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9p3U-0007Vt-00 for disman@ietf.org; Wed, 15 Oct 2003 13:03:24 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A9p3T-0007VI-00 for disman@ietf.org; Wed, 15 Oct 2003 13:03:23 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9FH2pF10031 for ; Wed, 15 Oct 2003 13:02:52 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66409P>; Wed, 15 Oct 2003 13:02:52 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408E9A004@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] section 3.3.3 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: Wed, 15 Oct 2003 13:02:47 -0400 Hi The following is the proposed resolution to Randy-24 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 3.3.3, replace "The Alarm MIB provides a means to tell what Notifications are just informational events or not of interest to the manager for other reasons by not including them in any alarm models. In addition," With "The Alarm MIB provides a means to determine whether a given notification is not of interest to managers for purposes of alarm management by permitting inspection of the alarm models. If no entries in the alarmModelTable could match a particular notification, then that notification is not relevant to the alarm models defined. In addition," Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 07, 2003 2:43 PM To: Disman (E-mail) Subject: [Disman] section 3.3.3 in 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 ... > 24) Section 3.3.3: the first sentence is a bit hard to swallow: > as a practical matter, to find out which notifications are > not of interest, one would have to walk the alarm model table > to find out what *is* of interest, and then remove that set > from the set of all possible notifications, which isn't listed > in any convenient spot. ... Proposed fix: CURRENT: The Alarm MIB provides a means to tell what Notifications are just informational events or not of interest to the manager for other reasons by not including them in any alarm models. In addition, REPLACEMENT: The Alarm MIB provides a means to determine whether a given notification is not of interest to managers for purposes of alarm management by permitting inspection of the alarm models. If no entries in the alarmModelTable could match a particular notification, then that notification is not relevant to the alarm models defined. In addition, Randy From exim@www1.ietf.org Wed Oct 15 13:04:24 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 NAA09554 for ; Wed, 15 Oct 2003 13:04:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9p46-0004d2-LY for disman-archive@odin.ietf.org; Wed, 15 Oct 2003 13:04:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FH42Ui017786 for disman-archive@odin.ietf.org; Wed, 15 Oct 2003 13:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9p46-0004cn-I1 for disman-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 13:04:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09477 for ; Wed, 15 Oct 2003 13:03:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9p44-0007X1-00 for disman-web-archive@ietf.org; Wed, 15 Oct 2003 13:04:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9p44-0007Wy-00 for disman-web-archive@ietf.org; Wed, 15 Oct 2003 13:04:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9p45-0004cG-6G; Wed, 15 Oct 2003 13:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9p3W-0004YC-6v for disman@optimus.ietf.org; Wed, 15 Oct 2003 13:03:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09423 for ; Wed, 15 Oct 2003 13:03:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9p3U-0007Vt-00 for disman@ietf.org; Wed, 15 Oct 2003 13:03:24 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A9p3T-0007VI-00 for disman@ietf.org; Wed, 15 Oct 2003 13:03:23 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9FH2pF10031 for ; Wed, 15 Oct 2003 13:02:52 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66409P>; Wed, 15 Oct 2003 13:02:52 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408E9A004@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] section 3.3.3 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: Wed, 15 Oct 2003 13:02:47 -0400 Hi The following is the proposed resolution to Randy-24 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 3.3.3, replace "The Alarm MIB provides a means to tell what Notifications are just informational events or not of interest to the manager for other reasons by not including them in any alarm models. In addition," With "The Alarm MIB provides a means to determine whether a given notification is not of interest to managers for purposes of alarm management by permitting inspection of the alarm models. If no entries in the alarmModelTable could match a particular notification, then that notification is not relevant to the alarm models defined. In addition," Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 07, 2003 2:43 PM To: Disman (E-mail) Subject: [Disman] section 3.3.3 in 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 ... > 24) Section 3.3.3: the first sentence is a bit hard to swallow: > as a practical matter, to find out which notifications are > not of interest, one would have to walk the alarm model table > to find out what *is* of interest, and then remove that set > from the set of all possible notifications, which isn't listed > in any convenient spot. ... Proposed fix: CURRENT: The Alarm MIB provides a means to tell what Notifications are just informational events or not of interest to the manager for other reasons by not including them in any alarm models. In addition, REPLACEMENT: The Alarm MIB provides a means to determine whether a given notification is not of interest to managers for purposes of alarm management by permitting inspection of the alarm models. If no entries in the alarmModelTable could match a particular notification, then that notification is not relevant to the alarm models defined. In addition, Randy From disman-admin@ietf.org Wed Oct 15 13:16: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 NAA10954 for ; Wed, 15 Oct 2003 13:16:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9pFg-0005jW-4v; Wed, 15 Oct 2003 13:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9pFE-0005ic-IK for disman@optimus.ietf.org; Wed, 15 Oct 2003 13:15:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10924 for ; Wed, 15 Oct 2003 13:15:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9pFC-0000Dc-00 for disman@ietf.org; Wed, 15 Oct 2003 13:15:30 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A9pFA-0000Co-00 for disman@ietf.org; Wed, 15 Oct 2003 13:15:28 -0400 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 h9FHEuM21112 for ; Wed, 15 Oct 2003 13:14:56 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66VA24>; Wed, 15 Oct 2003 13:14:57 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408E9A030@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: Wed, 15 Oct 2003 13:14:55 -0400 Hi The following is the proposed resolution to Randy-68. Assuming no objection, this item will is closed with no changes to the draft. ituAlarmGenericModel is useful, not redundant. alarmModelTable has INDEX { alarmListName, alarmModelIndex, alarmModelState } ituAlarmTable has INDEX { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity } Where alarmModelState != ituAlarmPerceivedSeverity You may be able to figure out which row in the alarmModelTable this refers to but maintaining the pointer makes this much faster and reliable. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 07, 2003 3:25 PM To: Disman (E-mail) Subject: [Disman] ituAlarmGenericModel is redundant? 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 ... > 68) ituAlarmGenericModel: why is this object needed? the indexing > information needed to find the model entry is the same for both > tables. ... ituAlarmGenericModel seems comepletely redundant. All the information needed to find the alarmModelEntry corresponding to an ituAlarmEntry is already present in that entry's indexes. This object serves no purpose. Proposal: remove ituAlarmGenericModel. Randy From exim@www1.ietf.org Wed Oct 15 13:16: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 NAA10969 for ; Wed, 15 Oct 2003 13:16:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9pFi-0005kO-4w for disman-archive@odin.ietf.org; Wed, 15 Oct 2003 13:16:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FHG2XL022089 for disman-archive@odin.ietf.org; Wed, 15 Oct 2003 13:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9pFi-0005kC-1l for disman-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 13:16:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10940 for ; Wed, 15 Oct 2003 13:15:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9pFf-0000Dz-00 for disman-web-archive@ietf.org; Wed, 15 Oct 2003 13:16:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9pFf-0000Dw-00 for disman-web-archive@ietf.org; Wed, 15 Oct 2003 13:15:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9pFg-0005jW-4v; Wed, 15 Oct 2003 13:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9pFE-0005ic-IK for disman@optimus.ietf.org; Wed, 15 Oct 2003 13:15:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10924 for ; Wed, 15 Oct 2003 13:15:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9pFC-0000Dc-00 for disman@ietf.org; Wed, 15 Oct 2003 13:15:30 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A9pFA-0000Co-00 for disman@ietf.org; Wed, 15 Oct 2003 13:15:28 -0400 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 h9FHEuM21112 for ; Wed, 15 Oct 2003 13:14:56 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66VA24>; Wed, 15 Oct 2003 13:14:57 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408E9A030@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: Wed, 15 Oct 2003 13:14:55 -0400 Hi The following is the proposed resolution to Randy-68. Assuming no objection, this item will is closed with no changes to the draft. ituAlarmGenericModel is useful, not redundant. alarmModelTable has INDEX { alarmListName, alarmModelIndex, alarmModelState } ituAlarmTable has INDEX { alarmListName, alarmModelIndex, ituAlarmPerceivedSeverity } Where alarmModelState != ituAlarmPerceivedSeverity You may be able to figure out which row in the alarmModelTable this refers to but maintaining the pointer makes this much faster and reliable. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 07, 2003 3:25 PM To: Disman (E-mail) Subject: [Disman] ituAlarmGenericModel is redundant? 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 ... > 68) ituAlarmGenericModel: why is this object needed? the indexing > information needed to find the model entry is the same for both > tables. ... ituAlarmGenericModel seems comepletely redundant. All the information needed to find the alarmModelEntry corresponding to an ituAlarmEntry is already present in that entry's indexes. This object serves no purpose. Proposal: remove ituAlarmGenericModel. Randy From disman-admin@ietf.org Thu Oct 16 12:08:32 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 MAA08362 for ; Thu, 16 Oct 2003 12:08:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAfT-0002oL-5e; Thu, 16 Oct 2003 12:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAfB-0002mS-9v for disman@optimus.ietf.org; Thu, 16 Oct 2003 12:07:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08346 for ; Thu, 16 Oct 2003 12:07:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAf9-0006Ga-00 for disman@ietf.org; Thu, 16 Oct 2003 12:07:43 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1AAAf9-0006GW-00 for disman@ietf.org; Thu, 16 Oct 2003 12:07:43 -0400 Received: from h-69-3-242-230.snvacaid.dynamic.covad.net ([69.3.242.230] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AAAf5-0004ZZ-00 for disman@ietf.org; Thu, 16 Oct 2003 09:07:39 -0700 Message-ID: <002b01c393ff$b1a17d40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408E99FE9@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Section 4.1.5 in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 09:08:00 -0700 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 Thu Oct 16 12:08:34 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 MAA08377 for ; Thu, 16 Oct 2003 12:08:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAfe-0002rc-2R for disman-archive@odin.ietf.org; Thu, 16 Oct 2003 12:08:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GG8Eng011002 for disman-archive@odin.ietf.org; Thu, 16 Oct 2003 12:08:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAfd-0002rN-Td for disman-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 12:08:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08357 for ; Thu, 16 Oct 2003 12:08:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAfc-0006Go-00 for disman-web-archive@ietf.org; Thu, 16 Oct 2003 12:08:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAAfc-0006Gl-00 for disman-web-archive@ietf.org; Thu, 16 Oct 2003 12:08:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAfT-0002oL-5e; Thu, 16 Oct 2003 12:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAfB-0002mS-9v for disman@optimus.ietf.org; Thu, 16 Oct 2003 12:07:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08346 for ; Thu, 16 Oct 2003 12:07:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAf9-0006Ga-00 for disman@ietf.org; Thu, 16 Oct 2003 12:07:43 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1AAAf9-0006GW-00 for disman@ietf.org; Thu, 16 Oct 2003 12:07:43 -0400 Received: from h-69-3-242-230.snvacaid.dynamic.covad.net ([69.3.242.230] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AAAf5-0004ZZ-00 for disman@ietf.org; Thu, 16 Oct 2003 09:07:39 -0700 Message-ID: <002b01c393ff$b1a17d40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408E99FE9@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Section 4.1.5 in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 09:08:00 -0700 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 Thu Oct 16 12:18: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 MAA08668 for ; Thu, 16 Oct 2003 12:18:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAp7-0003Nb-0K; Thu, 16 Oct 2003 12:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAoc-0003Mq-Em for disman@optimus.ietf.org; Thu, 16 Oct 2003 12:17:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08646 for ; Thu, 16 Oct 2003 12:17:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAob-0006MR-00 for disman@ietf.org; Thu, 16 Oct 2003 12:17:29 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1AAAoa-0006MO-00 for disman@ietf.org; Thu, 16 Oct 2003 12:17:28 -0400 Received: from h-69-3-242-230.snvacaid.dynamic.covad.net ([69.3.242.230] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AAAoZ-0004pN-00 for disman@ietf.org; Thu, 16 Oct 2003 09:17:27 -0700 Message-ID: <003201c39401$0fa29fe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408E9A030@zcard0ka.ca.nortel.com> Subject: Re: [Disman] ituAlarmGenericModel is redundant? 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: Thu, 16 Oct 2003 09:17:57 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Wednesday, October 15, 2003 10:14 AM > Subject: RE: [Disman] ituAlarmGenericModel is redundant? ... > The following is the proposed resolution to Randy-68. Assuming no objection, > this item will is closed with no changes to the draft. > > ituAlarmGenericModel is useful, not redundant. > > alarmModelTable has > > INDEX { alarmListName, alarmModelIndex, alarmModelState } > > ituAlarmTable has > > INDEX { alarmListName, alarmModelIndex, > ituAlarmPerceivedSeverity } > > Where alarmModelState != ituAlarmPerceivedSeverity > > You may be able to figure out which row in the alarmModelTable this refers > to but maintaining the pointer makes this much faster and reliable. ... Ah. Thank you. The purpose of this object is to avoid having to scan the alarmModelSpecificPointers for a given model to figure out the mapping. Though I think that's kinda weak, I'm willing to accept the rationale. HOWEVER, Now I *really* want to know how these itu entries come into (and go out of) existence as alarm models come and go. Randy From exim@www1.ietf.org Thu Oct 16 12:18:22 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 MAA08685 for ; Thu, 16 Oct 2003 12:18:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAp8-0003Qe-Qr for disman-archive@odin.ietf.org; Thu, 16 Oct 2003 12:18:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GGI2X2013171 for disman-archive@odin.ietf.org; Thu, 16 Oct 2003 12:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAp8-0003PR-JX for disman-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 12:18:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08664 for ; Thu, 16 Oct 2003 12:17:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAp7-0006Mn-00 for disman-web-archive@ietf.org; Thu, 16 Oct 2003 12:18:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAAp6-0006Mk-00 for disman-web-archive@ietf.org; Thu, 16 Oct 2003 12:18:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAp7-0003Nb-0K; Thu, 16 Oct 2003 12:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAoc-0003Mq-Em for disman@optimus.ietf.org; Thu, 16 Oct 2003 12:17:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08646 for ; Thu, 16 Oct 2003 12:17:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAob-0006MR-00 for disman@ietf.org; Thu, 16 Oct 2003 12:17:29 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1AAAoa-0006MO-00 for disman@ietf.org; Thu, 16 Oct 2003 12:17:28 -0400 Received: from h-69-3-242-230.snvacaid.dynamic.covad.net ([69.3.242.230] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AAAoZ-0004pN-00 for disman@ietf.org; Thu, 16 Oct 2003 09:17:27 -0700 Message-ID: <003201c39401$0fa29fe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408E9A030@zcard0ka.ca.nortel.com> Subject: Re: [Disman] ituAlarmGenericModel is redundant? 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: Thu, 16 Oct 2003 09:17:57 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Wednesday, October 15, 2003 10:14 AM > Subject: RE: [Disman] ituAlarmGenericModel is redundant? ... > The following is the proposed resolution to Randy-68. Assuming no objection, > this item will is closed with no changes to the draft. > > ituAlarmGenericModel is useful, not redundant. > > alarmModelTable has > > INDEX { alarmListName, alarmModelIndex, alarmModelState } > > ituAlarmTable has > > INDEX { alarmListName, alarmModelIndex, > ituAlarmPerceivedSeverity } > > Where alarmModelState != ituAlarmPerceivedSeverity > > You may be able to figure out which row in the alarmModelTable this refers > to but maintaining the pointer makes this much faster and reliable. ... Ah. Thank you. The purpose of this object is to avoid having to scan the alarmModelSpecificPointers for a given model to figure out the mapping. Though I think that's kinda weak, I'm willing to accept the rationale. HOWEVER, Now I *really* want to know how these itu entries come into (and go out of) existence as alarm models come and go. Randy From disman-admin@ietf.org Thu Oct 16 13:24: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 NAA11921 for ; Thu, 16 Oct 2003 13:24:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AABqy-0006fm-OT; Thu, 16 Oct 2003 13:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AABqV-0006eS-P7 for disman@optimus.ietf.org; Thu, 16 Oct 2003 13:23:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11840; Thu, 16 Oct 2003 13:23:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AABqO-0007KF-00; Thu, 16 Oct 2003 13:23:24 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1AABqN-0007KC-00; Thu, 16 Oct 2003 13:23:24 -0400 Received: from h-69-3-242-230.snvacaid.dynamic.covad.net ([69.3.242.230] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AABqL-0003gP-00; Thu, 16 Oct 2003 10:23:21 -0700 Message-ID: <005001c3940a$44f1ffc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: "Bert Wijnen" , "Scott Bradner \(E-mail\)" , "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] Response to ITU-T SG 4 Liaison on Alarm MIB Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 10:23:51 -0700 From: IETF Disman Working Group To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 Title: Response to Liaison on Alarm MIB Response Contact: Randy Presuhn randy_presuhn@mindspring.com Technical Contact: disman@ietf.org Purpose: In Reply to Liaison Thank you for the interest in the Alarm MIB. The latest version is currently completing Area Director Review and can be found at http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt The Distributed Management (disman) working group hopes to advance the current I-D to Proposed Standard, with minimal changes. In the future, if the working group is chartered with an Alarm MIB version 2, we will be interested in cooperating with you to ensure your requirements are considered. On a related item, the IESG has approved publication of the Alarm Reporting Control MIB as a Proposed Standard. The file given to the RFC editor is at http://www.ietf.org/internet-drafts/draft-ietf-disman-conditionmib-10.txt We look forward to the continued participation of SG 4 experts in our work. Sincerely, Randy Presuhn Chair, IETF disman working group From exim@www1.ietf.org Thu Oct 16 13:24:29 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 NAA11936 for ; Thu, 16 Oct 2003 13:24:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AABr8-0006hF-GB for disman-archive@odin.ietf.org; Thu, 16 Oct 2003 13:24:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GHOA1m025735 for disman-archive@odin.ietf.org; Thu, 16 Oct 2003 13:24:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AABr8-0006h0-9I for disman-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 13:24:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11913 for ; Thu, 16 Oct 2003 13:23:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AABr6-0007LI-00 for disman-web-archive@ietf.org; Thu, 16 Oct 2003 13:24:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AABr5-0007LE-00 for disman-web-archive@ietf.org; Thu, 16 Oct 2003 13:24:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AABqy-0006fm-OT; Thu, 16 Oct 2003 13:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AABqV-0006eS-P7 for disman@optimus.ietf.org; Thu, 16 Oct 2003 13:23:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11840; Thu, 16 Oct 2003 13:23:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AABqO-0007KF-00; Thu, 16 Oct 2003 13:23:24 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1AABqN-0007KC-00; Thu, 16 Oct 2003 13:23:24 -0400 Received: from h-69-3-242-230.snvacaid.dynamic.covad.net ([69.3.242.230] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AABqL-0003gP-00; Thu, 16 Oct 2003 10:23:21 -0700 Message-ID: <005001c3940a$44f1ffc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: "Bert Wijnen" , "Scott Bradner \(E-mail\)" , "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] Response to ITU-T SG 4 Liaison on Alarm MIB Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 10:23:51 -0700 From: IETF Disman Working Group To: ITU-T Study Group 4 - Q12/4, Q17/4, Q19/4 Title: Response to Liaison on Alarm MIB Response Contact: Randy Presuhn randy_presuhn@mindspring.com Technical Contact: disman@ietf.org Purpose: In Reply to Liaison Thank you for the interest in the Alarm MIB. The latest version is currently completing Area Director Review and can be found at http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-15.txt The Distributed Management (disman) working group hopes to advance the current I-D to Proposed Standard, with minimal changes. In the future, if the working group is chartered with an Alarm MIB version 2, we will be interested in cooperating with you to ensure your requirements are considered. On a related item, the IESG has approved publication of the Alarm Reporting Control MIB as a Proposed Standard. The file given to the RFC editor is at http://www.ietf.org/internet-drafts/draft-ietf-disman-conditionmib-10.txt We look forward to the continued participation of SG 4 experts in our work. Sincerely, Randy Presuhn Chair, IETF disman working group From disman-admin@ietf.org Thu Oct 16 16:18:40 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 QAA21805 for ; Thu, 16 Oct 2003 16:18:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAEZN-0008Gq-79; Thu, 16 Oct 2003 16:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAEYX-0008Dk-Q9 for disman@optimus.ietf.org; Thu, 16 Oct 2003 16:17:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21602 for ; Thu, 16 Oct 2003 16:16:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAEYV-0001kW-00 for disman@ietf.org; Thu, 16 Oct 2003 16:17:07 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AAEYR-0001iw-00 for disman@ietf.org; Thu, 16 Oct 2003 16:17:03 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9GKGLj17009 for ; Thu, 16 Oct 2003 16:16:22 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66VX0C>; Thu, 16 Oct 2003 16:16:21 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408E9ABF2@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: Thu, 16 Oct 2003 16:16:20 -0400 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 Thu Oct 16 16:18:42 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 QAA21826 for ; Thu, 16 Oct 2003 16:18:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAEZg-0008IY-RP for disman-archive@odin.ietf.org; Thu, 16 Oct 2003 16:18:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GKIKqM031894 for disman-archive@odin.ietf.org; Thu, 16 Oct 2003 16:18:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAEZg-0008IL-Mz for disman-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 16:18:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21739 for ; Thu, 16 Oct 2003 16:18:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAEZe-0001nX-00 for disman-web-archive@ietf.org; Thu, 16 Oct 2003 16:18:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAEZe-0001nU-00 for disman-web-archive@ietf.org; Thu, 16 Oct 2003 16:18:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAEZN-0008Gq-79; Thu, 16 Oct 2003 16:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAEYX-0008Dk-Q9 for disman@optimus.ietf.org; Thu, 16 Oct 2003 16:17:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21602 for ; Thu, 16 Oct 2003 16:16:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAEYV-0001kW-00 for disman@ietf.org; Thu, 16 Oct 2003 16:17:07 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AAEYR-0001iw-00 for disman@ietf.org; Thu, 16 Oct 2003 16:17:03 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9GKGLj17009 for ; Thu, 16 Oct 2003 16:16:22 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66VX0C>; Thu, 16 Oct 2003 16:16:21 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408E9ABF2@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: Thu, 16 Oct 2003 16:16:20 -0400 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 Thu Oct 16 17:04: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 RAA25103 for ; Thu, 16 Oct 2003 17:04:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAFHs-0002oi-RQ; Thu, 16 Oct 2003 17:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAFHD-0002o8-TA for disman@optimus.ietf.org; Thu, 16 Oct 2003 17:03:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25051 for ; Thu, 16 Oct 2003 17:03:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAFHB-0002qM-00 for disman@ietf.org; Thu, 16 Oct 2003 17:03:17 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1AAFHB-0002qC-00 for disman@ietf.org; Thu, 16 Oct 2003 17:03:17 -0400 Received: from h-69-3-242-230.snvacaid.dynamic.covad.net ([69.3.242.230] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AAFH8-0007Af-00 for disman@ietf.org; Thu, 16 Oct 2003 14:03:14 -0700 Message-ID: <000601c39428$fd43fd80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408E9ABF2@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 14:03:46 -0700 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 Thu Oct 16 17:04:52 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 RAA25141 for ; Thu, 16 Oct 2003 17:04:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAFIO-0002rk-PX for disman-archive@odin.ietf.org; Thu, 16 Oct 2003 17:04:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GL4WLL011015 for disman-archive@odin.ietf.org; Thu, 16 Oct 2003 17:04:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAFIO-0002ra-JA for disman-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 17:04:32 -0400 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 RAA25102 for ; Thu, 16 Oct 2003 17:04:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAFHs-0002oi-RQ; Thu, 16 Oct 2003 17:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAFHD-0002o8-TA for disman@optimus.ietf.org; Thu, 16 Oct 2003 17:03:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25051 for ; Thu, 16 Oct 2003 17:03:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAFHB-0002qM-00 for disman@ietf.org; Thu, 16 Oct 2003 17:03:17 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1AAFHB-0002qC-00 for disman@ietf.org; Thu, 16 Oct 2003 17:03:17 -0400 Received: from h-69-3-242-230.snvacaid.dynamic.covad.net ([69.3.242.230] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AAFH8-0007Af-00 for disman@ietf.org; Thu, 16 Oct 2003 14:03:14 -0700 Message-ID: <000601c39428$fd43fd80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408E9ABF2@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Oct 2003 14:03:46 -0700 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 Thu Oct 16 17:24:24 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 RAA25741 for ; Thu, 16 Oct 2003 17:24:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAFbF-00047d-1l; Thu, 16 Oct 2003 17:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAFaG-00046j-GT for disman@optimus.ietf.org; Thu, 16 Oct 2003 17:23:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25708 for ; Thu, 16 Oct 2003 17:22:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAFaE-00033P-00 for disman@ietf.org; Thu, 16 Oct 2003 17:22:58 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1AAFaD-00033M-00 for disman@ietf.org; Thu, 16 Oct 2003 17:22:57 -0400 Received: from h-69-3-242-230.snvacaid.dynamic.covad.net ([69.3.242.230] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AAFaC-0001hN-00 for disman@ietf.org; Thu, 16 Oct 2003 14:22:56 -0700 Message-ID: <002301c3942b$bd90e4c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Fw: training in Minneapolis 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, 16 Oct 2003 14:23:27 -0700 Hi - > From: > To: ; > Sent: Thursday, October 16, 2003 2:04 PM ... > We will also be presenting a new editor's training session in > Minneapolis, as follows: > > Sunday, November 10, 2003 > ========================= > 1330-1500 Editor's Training -- Conrad C > > Training for current or aspiring IETF document > editors. Covers the roles and responsibilities > of a document editor, and includes advice on > producing a high-quality IETF specification. > ... If you currently edit a document or are thinking about becoming an editor of a WG document, this is RECOMMENDED. Randy From exim@www1.ietf.org Thu Oct 16 17:24: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 RAA25756 for ; Thu, 16 Oct 2003 17:24:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAFbK-00049L-Mc for disman-archive@odin.ietf.org; Thu, 16 Oct 2003 17:24:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GLO6qB015948 for disman-archive@odin.ietf.org; Thu, 16 Oct 2003 17:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAFbK-000499-F7 for disman-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 17:24:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25722 for ; Thu, 16 Oct 2003 17:23:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAFbH-00033k-00 for disman-web-archive@ietf.org; Thu, 16 Oct 2003 17:24:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAFbH-00033h-00 for disman-web-archive@ietf.org; Thu, 16 Oct 2003 17:24:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAFbF-00047d-1l; Thu, 16 Oct 2003 17:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAFaG-00046j-GT for disman@optimus.ietf.org; Thu, 16 Oct 2003 17:23:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25708 for ; Thu, 16 Oct 2003 17:22:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAFaE-00033P-00 for disman@ietf.org; Thu, 16 Oct 2003 17:22:58 -0400 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1AAFaD-00033M-00 for disman@ietf.org; Thu, 16 Oct 2003 17:22:57 -0400 Received: from h-69-3-242-230.snvacaid.dynamic.covad.net ([69.3.242.230] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AAFaC-0001hN-00 for disman@ietf.org; Thu, 16 Oct 2003 14:22:56 -0700 Message-ID: <002301c3942b$bd90e4c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Fw: training in Minneapolis 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, 16 Oct 2003 14:23:27 -0700 Hi - > From: > To: ; > Sent: Thursday, October 16, 2003 2:04 PM ... > We will also be presenting a new editor's training session in > Minneapolis, as follows: > > Sunday, November 10, 2003 > ========================= > 1330-1500 Editor's Training -- Conrad C > > Training for current or aspiring IETF document > editors. Covers the roles and responsibilities > of a document editor, and includes advice on > producing a high-quality IETF specification. > ... If you currently edit a document or are thinking about becoming an editor of a WG document, this is RECOMMENDED. Randy From disman-admin@ietf.org Fri Oct 17 07:38: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 HAA28320 for ; Fri, 17 Oct 2003 07:38:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AASvi-0007mh-4U; Fri, 17 Oct 2003 07:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AASvZ-0007jn-2y for disman@optimus.ietf.org; Fri, 17 Oct 2003 07:37:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28309 for ; Fri, 17 Oct 2003 07:37:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AASvY-0002Tl-00 for disman@ietf.org; Fri, 17 Oct 2003 07:37:52 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AASvY-0002TX-00 for disman@ietf.org; Fri, 17 Oct 2003 07:37:52 -0400 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 h9HBbJd28278 for ; Fri, 17 Oct 2003 07:37:19 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66V8K3>; Fri, 17 Oct 2003 07:37:19 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408E9ADB2@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: Fri, 17 Oct 2003 07:37:18 -0400 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 Fri Oct 17 07:38:29 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 HAA28339 for ; Fri, 17 Oct 2003 07:38:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AASvm-0007p0-WC for disman-archive@odin.ietf.org; Fri, 17 Oct 2003 07:38:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HBc6uD030060 for disman-archive@odin.ietf.org; Fri, 17 Oct 2003 07:38:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AASvm-0007od-FR for disman-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 07:38:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28313 for ; Fri, 17 Oct 2003 07:37:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AASvl-0002Tx-00 for disman-web-archive@ietf.org; Fri, 17 Oct 2003 07:38:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AASvl-0002Tu-00 for disman-web-archive@ietf.org; Fri, 17 Oct 2003 07:38:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AASvi-0007mh-4U; Fri, 17 Oct 2003 07:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AASvZ-0007jn-2y for disman@optimus.ietf.org; Fri, 17 Oct 2003 07:37:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28309 for ; Fri, 17 Oct 2003 07:37:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AASvY-0002Tl-00 for disman@ietf.org; Fri, 17 Oct 2003 07:37:52 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AASvY-0002TX-00 for disman@ietf.org; Fri, 17 Oct 2003 07:37:52 -0400 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 h9HBbJd28278 for ; Fri, 17 Oct 2003 07:37:19 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66V8K3>; Fri, 17 Oct 2003 07:37:19 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408E9ADB2@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: Fri, 17 Oct 2003 07:37:18 -0400 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 Fri Oct 17 07:54: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 HAA28722 for ; Fri, 17 Oct 2003 07:54:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATBB-0008NW-B5; Fri, 17 Oct 2003 07:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATAq-0008Mx-TD for disman@optimus.ietf.org; Fri, 17 Oct 2003 07:53:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28678 for ; Fri, 17 Oct 2003 07:53:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AATAp-0002be-00 for disman@ietf.org; Fri, 17 Oct 2003 07:53:39 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AATAo-0002bS-00 for disman@ietf.org; Fri, 17 Oct 2003 07:53:39 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9HBr1E00780 for ; Fri, 17 Oct 2003 07:53:01 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66V8N7>; Fri, 17 Oct 2003 07:53:01 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408E9ADC6@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: Fri, 17 Oct 2003 07:53:00 -0400 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 Fri Oct 17 07:54: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 HAA28751 for ; Fri, 17 Oct 2003 07:54:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATBD-0008Pv-9L for disman-archive@odin.ietf.org; Fri, 17 Oct 2003 07:54:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HBs37x032349 for disman-archive@odin.ietf.org; Fri, 17 Oct 2003 07:54:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATBD-0008Oq-37 for disman-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 07:54:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28701 for ; Fri, 17 Oct 2003 07:53:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AATBC-0002bz-00 for disman-web-archive@ietf.org; Fri, 17 Oct 2003 07:54:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AATBB-0002bw-00 for disman-web-archive@ietf.org; Fri, 17 Oct 2003 07:54:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATBB-0008NW-B5; Fri, 17 Oct 2003 07:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATAq-0008Mx-TD for disman@optimus.ietf.org; Fri, 17 Oct 2003 07:53:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28678 for ; Fri, 17 Oct 2003 07:53:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AATAp-0002be-00 for disman@ietf.org; Fri, 17 Oct 2003 07:53:39 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AATAo-0002bS-00 for disman@ietf.org; Fri, 17 Oct 2003 07:53:39 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9HBr1E00780 for ; Fri, 17 Oct 2003 07:53:01 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66V8N7>; Fri, 17 Oct 2003 07:53:01 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408E9ADC6@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: Fri, 17 Oct 2003 07:53:00 -0400 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 Fri Oct 17 07:58: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 HAA28847 for ; Fri, 17 Oct 2003 07:58:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATF3-0000Gx-Dm; Fri, 17 Oct 2003 07:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATEy-0000Gm-3s for disman@optimus.ietf.org; Fri, 17 Oct 2003 07:57:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28828 for ; Fri, 17 Oct 2003 07:57:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AATEx-0002dv-00 for disman@ietf.org; Fri, 17 Oct 2003 07:57:55 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AATEw-0002ds-00 for disman@ietf.org; Fri, 17 Oct 2003 07:57:54 -0400 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 h9HBvMd28892 for ; Fri, 17 Oct 2003 07:57:22 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66V838>; Fri, 17 Oct 2003 07:57:22 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408E9ADCF@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] section 3.7 of alarm -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: Fri, 17 Oct 2003 07:57:21 -0400 Hi The following is the proposed resolution to Randy-28 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 3.7 replace " This format allows for the storage of any Trap or Notification that can be defined using SMIv1 or SMIv2." With " This format allows for the storage of any Trap or Notification type that can be defined using the SMI, or can be carried by SNMP." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 5:04 PM To: Disman (E-mail) Subject: [Disman] section 3.7 of alarm -15- 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 ... > 28) Section 3.7: "This format allows for the storage of any Trap > or Notification that can be defined using SMIv1 or SMIv2." > Not quite consistent with definition of "Notification"; > suggest "instance of any TRAP-TYPE or NOTIFICATION-TYPE", > though I think talking about SMIv1 and SMIv2 isn't helpful here. > See #47 below. > > Sharon-> I actually meant the SMI. ... How about this proposed replacement text: "This format allows for the storage of any Trap or Notification type that can be defined using the SMI, or can be carried by SNMP." Randy From exim@www1.ietf.org Fri Oct 17 07:58:24 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 HAA28862 for ; Fri, 17 Oct 2003 07:58:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATF4-0000Hk-J8 for disman-archive@odin.ietf.org; Fri, 17 Oct 2003 07:58:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HBw250001090 for disman-archive@odin.ietf.org; Fri, 17 Oct 2003 07:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATF4-0000HV-Dm for disman-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 07:58:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28832 for ; Fri, 17 Oct 2003 07:57:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AATF3-0002e1-00 for disman-web-archive@ietf.org; Fri, 17 Oct 2003 07:58:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AATF3-0002dy-00 for disman-web-archive@ietf.org; Fri, 17 Oct 2003 07:58:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATF3-0000Gx-Dm; Fri, 17 Oct 2003 07:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATEy-0000Gm-3s for disman@optimus.ietf.org; Fri, 17 Oct 2003 07:57:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28828 for ; Fri, 17 Oct 2003 07:57:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AATEx-0002dv-00 for disman@ietf.org; Fri, 17 Oct 2003 07:57:55 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AATEw-0002ds-00 for disman@ietf.org; Fri, 17 Oct 2003 07:57:54 -0400 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 h9HBvMd28892 for ; Fri, 17 Oct 2003 07:57:22 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66V838>; Fri, 17 Oct 2003 07:57:22 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408E9ADCF@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] section 3.7 of alarm -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: Fri, 17 Oct 2003 07:57:21 -0400 Hi The following is the proposed resolution to Randy-28 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 3.7 replace " This format allows for the storage of any Trap or Notification that can be defined using SMIv1 or SMIv2." With " This format allows for the storage of any Trap or Notification type that can be defined using the SMI, or can be carried by SNMP." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 5:04 PM To: Disman (E-mail) Subject: [Disman] section 3.7 of alarm -15- 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 ... > 28) Section 3.7: "This format allows for the storage of any Trap > or Notification that can be defined using SMIv1 or SMIv2." > Not quite consistent with definition of "Notification"; > suggest "instance of any TRAP-TYPE or NOTIFICATION-TYPE", > though I think talking about SMIv1 and SMIv2 isn't helpful here. > See #47 below. > > Sharon-> I actually meant the SMI. ... How about this proposed replacement text: "This format allows for the storage of any Trap or Notification type that can be defined using the SMI, or can be carried by SNMP." Randy From disman-admin@ietf.org Fri Oct 17 09:41: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 JAA01837 for ; Fri, 17 Oct 2003 09:41:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUqk-0005UY-Am; Fri, 17 Oct 2003 09:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUpu-0005SQ-JE for disman@optimus.ietf.org; Fri, 17 Oct 2003 09:40:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01782 for ; Fri, 17 Oct 2003 09:40:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAUps-0003Uz-00 for disman@ietf.org; Fri, 17 Oct 2003 09:40:08 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AAUpr-0003Uq-00 for disman@ietf.org; Fri, 17 Oct 2003 09:40:07 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9HDdTE16477 for ; Fri, 17 Oct 2003 09:39:29 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66V068>; Fri, 17 Oct 2003 09:39:29 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A29C@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] LocalSnmpEngineOrZeroLenStr in draft-ietf-disman-al arm-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: Fri, 17 Oct 2003 09:39:27 -0400 Hi The following is the proposed resolution to Randy-44 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the ALARM-MIB, replace " LocalSnmpEngineOrZeroLenStr ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An SNMP Engine ID or a zero-length string. The instantiation of this object will provide guidance on when this will be an SNMP Engine ID and when it will be a zero lengths string" SYNTAX OCTET STRING (SIZE(0 | 5..32))" With " -- LocalSnmpEngineOrZeroLenStr is intended to be a general -- textual convention that can be used outside of the set of -- MIBs related to Alarm Management. LocalSnmpEngineOrZeroLenStr ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An SNMP Engine ID or a zero-length string. The instantiation of this textual convention will provide guidance on when this will be an SNMP Engine ID and when it will be a zero lengths string" SYNTAX OCTET STRING (SIZE(0 | 5..32))" And in the description of alarmActiveEngineID replace " "The identification of the SNMP engine at which the alarm originated. If the alarm list can contain alarms from only one engine or the alarm is from an SNMPv1 system, this object is a zero length string." With " "The identification of the SNMP engine at which the alarm originated. If the alarm is from an SNMPv1 system this object is a zero length string." And in the description of alarmClearEngineID replace " The identification of the SNMP engine at which the alarm originated. If the alarm list can contain Notifications from only one engine or the trap is from an SNMPv1 system, this object is a zero length string." With " The identification of the SNMP engine at which the alarm originated. If the alarm is from an SNMPv1 system this object is a zero length string." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 10, 2003 11:59 PM To: Disman (E-mail) Subject: Re: [Disman] LocalSnmpEngineOrZeroLenStr in draft-ietf-disman-alarm-mib-15.txt Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Friday, October 10, 2003 12:44 PM > Subject: RE: [Disman] LocalSnmpEngineOrZeroLenStr in > draft-ietf-disman-alarm-mib-15.txt ... > I don't get your issue with the word instantiate > (http://dictionary.reference.com/search?r=2&q=instantiate). Textual > conventions are abstract. When we use them in object definitions they > are concrete. It talks about "instantiation of this object". In a TC definition, what could "this object" possibly refer to? Again, in all the cases where the TC is used, the conditions for zero length are the same, so why not simply factor that commonality back into the TC definition, and get rid of the indirection? > The 'Local' refers to where the alarm originated. So on a distributed > manager, there could potentially be different engine IDs. This is > explained in the instantiation of the TC. But as these are presently written, it sounds like the value has to be zero-length string until it has received things with different engineIDs. I'm sure that's not what's intended. > Sharon > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Thursday, October 02, 2003 11:18 PM > To: Disman (E-mail) > Subject: [Disman] LocalSnmpEngineOrZeroLenStr in > 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 > ... > > 44) page 15 (LocalSnmpEngineOrZeroLenStr): where the DESCRIPTION > > talks about "instantiation" doesn't make sense. I think it's > > referring to use of the TC in an OBJECT-TYPE definition, rather > > than object instantiation. > > > > Sharon -> This seems more a wordsmith thing. > ... > > The DESCRIPTION still doesn't make sense. It currently says: > "An SNMP Engine ID or a zero-length string. The > instantiation of this object will provide guidance > on when this will be an SNMP Engine ID and when it > will be a zero lengths string" > > This is a TC definition, so "instantiation of this object will provide > guidance" makes no sense at all to me. In both cases where this TC is > used, the conditions for a zero-length string value are the same: > either the notification came from a protocol (SNMPv1 is not the only > one! don't forget > SNMPv2c) which doesn't use SNMP Engine ID, or all entries in the table > currently have the same Engine ID. (I guess that means that when one > arrives from some other engine, all these objects' values will change from > zero-length string back to their "real" values. Am I the only person > bothered by this?) > > Randy > > > > From exim@www1.ietf.org Fri Oct 17 09:41:32 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 JAA01852 for ; Fri, 17 Oct 2003 09:41:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUqt-0005VT-2U for disman-archive@odin.ietf.org; Fri, 17 Oct 2003 09:41:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HDfB9f021161 for disman-archive@odin.ietf.org; Fri, 17 Oct 2003 09:41:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUqs-0005VE-Ut for disman-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 09:41:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01815 for ; Fri, 17 Oct 2003 09:41:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAUqq-0003WA-00 for disman-web-archive@ietf.org; Fri, 17 Oct 2003 09:41:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAUqq-0003W7-00 for disman-web-archive@ietf.org; Fri, 17 Oct 2003 09:41:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUqk-0005UY-Am; Fri, 17 Oct 2003 09:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUpu-0005SQ-JE for disman@optimus.ietf.org; Fri, 17 Oct 2003 09:40:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01782 for ; Fri, 17 Oct 2003 09:40:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAUps-0003Uz-00 for disman@ietf.org; Fri, 17 Oct 2003 09:40:08 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AAUpr-0003Uq-00 for disman@ietf.org; Fri, 17 Oct 2003 09:40:07 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9HDdTE16477 for ; Fri, 17 Oct 2003 09:39:29 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66V068>; Fri, 17 Oct 2003 09:39:29 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A29C@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] LocalSnmpEngineOrZeroLenStr in draft-ietf-disman-al arm-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: Fri, 17 Oct 2003 09:39:27 -0400 Hi The following is the proposed resolution to Randy-44 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the ALARM-MIB, replace " LocalSnmpEngineOrZeroLenStr ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An SNMP Engine ID or a zero-length string. The instantiation of this object will provide guidance on when this will be an SNMP Engine ID and when it will be a zero lengths string" SYNTAX OCTET STRING (SIZE(0 | 5..32))" With " -- LocalSnmpEngineOrZeroLenStr is intended to be a general -- textual convention that can be used outside of the set of -- MIBs related to Alarm Management. LocalSnmpEngineOrZeroLenStr ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An SNMP Engine ID or a zero-length string. The instantiation of this textual convention will provide guidance on when this will be an SNMP Engine ID and when it will be a zero lengths string" SYNTAX OCTET STRING (SIZE(0 | 5..32))" And in the description of alarmActiveEngineID replace " "The identification of the SNMP engine at which the alarm originated. If the alarm list can contain alarms from only one engine or the alarm is from an SNMPv1 system, this object is a zero length string." With " "The identification of the SNMP engine at which the alarm originated. If the alarm is from an SNMPv1 system this object is a zero length string." And in the description of alarmClearEngineID replace " The identification of the SNMP engine at which the alarm originated. If the alarm list can contain Notifications from only one engine or the trap is from an SNMPv1 system, this object is a zero length string." With " The identification of the SNMP engine at which the alarm originated. If the alarm is from an SNMPv1 system this object is a zero length string." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 10, 2003 11:59 PM To: Disman (E-mail) Subject: Re: [Disman] LocalSnmpEngineOrZeroLenStr in draft-ietf-disman-alarm-mib-15.txt Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Friday, October 10, 2003 12:44 PM > Subject: RE: [Disman] LocalSnmpEngineOrZeroLenStr in > draft-ietf-disman-alarm-mib-15.txt ... > I don't get your issue with the word instantiate > (http://dictionary.reference.com/search?r=2&q=instantiate). Textual > conventions are abstract. When we use them in object definitions they > are concrete. It talks about "instantiation of this object". In a TC definition, what could "this object" possibly refer to? Again, in all the cases where the TC is used, the conditions for zero length are the same, so why not simply factor that commonality back into the TC definition, and get rid of the indirection? > The 'Local' refers to where the alarm originated. So on a distributed > manager, there could potentially be different engine IDs. This is > explained in the instantiation of the TC. But as these are presently written, it sounds like the value has to be zero-length string until it has received things with different engineIDs. I'm sure that's not what's intended. > Sharon > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Thursday, October 02, 2003 11:18 PM > To: Disman (E-mail) > Subject: [Disman] LocalSnmpEngineOrZeroLenStr in > 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 > ... > > 44) page 15 (LocalSnmpEngineOrZeroLenStr): where the DESCRIPTION > > talks about "instantiation" doesn't make sense. I think it's > > referring to use of the TC in an OBJECT-TYPE definition, rather > > than object instantiation. > > > > Sharon -> This seems more a wordsmith thing. > ... > > The DESCRIPTION still doesn't make sense. It currently says: > "An SNMP Engine ID or a zero-length string. The > instantiation of this object will provide guidance > on when this will be an SNMP Engine ID and when it > will be a zero lengths string" > > This is a TC definition, so "instantiation of this object will provide > guidance" makes no sense at all to me. In both cases where this TC is > used, the conditions for a zero-length string value are the same: > either the notification came from a protocol (SNMPv1 is not the only > one! don't forget > SNMPv2c) which doesn't use SNMP Engine ID, or all entries in the table > currently have the same Engine ID. (I guess that means that when one > arrives from some other engine, all these objects' values will change from > zero-length string back to their "real" values. Am I the only person > bothered by this?) > > Randy > > > > From disman-admin@ietf.org Fri Oct 17 14:17: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 OAA14238 for ; Fri, 17 Oct 2003 14:17:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZ9o-0002t0-Us; Fri, 17 Oct 2003 14:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZ8x-0002rB-HC for disman@optimus.ietf.org; Fri, 17 Oct 2003 14:16:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14131 for ; Fri, 17 Oct 2003 14:15:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZ8u-0006ji-00 for disman@ietf.org; Fri, 17 Oct 2003 14:16:04 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AAZ8u-0006jc-00 for disman@ietf.org; Fri, 17 Oct 2003 14:16:04 -0400 Received: from h-68-164-80-100.snvacaid.dynamic.covad.net ([68.164.80.100] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AAZ8q-0006LF-00 for disman@ietf.org; Fri, 17 Oct 2003 11:16:00 -0700 Message-ID: <004c01c394da$cb46c4e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408E9ADC6@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 11:16:32 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Friday, October 17, 2003 4:53 AM > 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." ... Why would they (want/need) to create separate alarm lists in order to specify alarms from sources in different SNMP contexts? I'm glad the IP business is resolved, but I return to my original question: > > 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 Fri Oct 17 14:17:32 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 OAA14253 for ; Fri, 17 Oct 2003 14:17:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZ9z-0002wT-Gc for disman-archive@odin.ietf.org; Fri, 17 Oct 2003 14:17:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HIHBPs011287 for disman-archive@odin.ietf.org; Fri, 17 Oct 2003 14:17:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZ9z-0002vR-7X for disman-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 14:17:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14226 for ; Fri, 17 Oct 2003 14:17:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZ9w-0006lB-00 for disman-web-archive@ietf.org; Fri, 17 Oct 2003 14:17:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAZ9w-0006l5-00 for disman-web-archive@ietf.org; Fri, 17 Oct 2003 14:17:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZ9o-0002t0-Us; Fri, 17 Oct 2003 14:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZ8x-0002rB-HC for disman@optimus.ietf.org; Fri, 17 Oct 2003 14:16:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14131 for ; Fri, 17 Oct 2003 14:15:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZ8u-0006ji-00 for disman@ietf.org; Fri, 17 Oct 2003 14:16:04 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AAZ8u-0006jc-00 for disman@ietf.org; Fri, 17 Oct 2003 14:16:04 -0400 Received: from h-68-164-80-100.snvacaid.dynamic.covad.net ([68.164.80.100] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AAZ8q-0006LF-00 for disman@ietf.org; Fri, 17 Oct 2003 11:16:00 -0700 Message-ID: <004c01c394da$cb46c4e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408E9ADC6@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 11:16:32 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Friday, October 17, 2003 4:53 AM > 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." ... Why would they (want/need) to create separate alarm lists in order to specify alarms from sources in different SNMP contexts? I'm glad the IP business is resolved, but I return to my original question: > > 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 Fri Oct 17 14:35: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 OAA15147 for ; Fri, 17 Oct 2003 14:35:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZRF-0003gW-TQ; Fri, 17 Oct 2003 14:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZQJ-0003fh-Q3 for disman@optimus.ietf.org; Fri, 17 Oct 2003 14:34:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15115 for ; Fri, 17 Oct 2003 14:33:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZQ4-0006yf-00 for disman@ietf.org; Fri, 17 Oct 2003 14:33:48 -0400 Received: from colossus.systems.pipex.net ([62.241.160.73]) by ietf-mx with esmtp (Exim 4.12) id 1AAZQ4-0006yY-00 for disman@ietf.org; Fri, 17 Oct 2003 14:33:48 -0400 Received: from tom3 (1Cust85.tnt30.lnd3.gbr.da.uu.net [62.188.122.85]) by colossus.systems.pipex.net (Postfix) with SMTP id 6C65E16002C82; Fri, 17 Oct 2003 19:33:12 +0100 (BST) Message-ID: <001301c394dc$bba87040$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Sharon Chisholm" , "Disman (E-mail)" Subject: Re: [Disman] section 3.3.3 in draft-ietf-disman-alarm-mib-15.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 19:21:27 +0100 Content-Transfer-Encoding: 7bit I now find this harder to comprehend and no longer know whether I agree with it or not:-( Is it saying "The Alarm MIB allows a manager to specify which Notifications are of interest for the purposes of alarm management (by having entries for those Notifications in the alarmModelTable). If no entries in the alarmModelTable match a particular Notification, then that Notification plays no part in the defined alarm models. In addition,..." If so, I propose a text along these lines, stressing the positive aspects not the negative. If not, then I no longer understand. Tom Petch -----Original Message----- From: Sharon Chisholm To: Disman (E-mail) Date: 15 October 2003 18:04 Subject: RE: [Disman] section 3.3.3 in draft-ietf-disman-alarm-mib-15.txt >Hi > >The following is the proposed resolution to Randy-24 Assuming no objection, >this item will be considered closed conditional on the proposed edit being >done. > >In section 3.3.3, replace > >"The Alarm MIB provides a means to tell what Notifications are just >informational events or not of interest to the manager for other reasons by >not including them in any alarm models. In addition," > >With >"The Alarm MIB provides a means to determine whether a given notification is >not of interest to managers for purposes of alarm management by permitting >inspection of the alarm models. If no entries in the alarmModelTable could >match a particular notification, then that notification is not relevant to >the alarm models defined. In addition," > >Sharon > >-----Original Message----- >From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >Sent: Tuesday, October 07, 2003 2:43 PM >To: Disman (E-mail) >Subject: [Disman] section 3.3.3 in 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 >... >> 24) Section 3.3.3: the first sentence is a bit hard to swallow: >> as a practical matter, to find out which notifications are >> not of interest, one would have to walk the alarm model table >> to find out what *is* of interest, and then remove that set >> from the set of all possible notifications, which isn't listed >> in any convenient spot. >... > >Proposed fix: > >CURRENT: >The Alarm MIB provides a means to tell what Notifications are just >informational events or not of interest to the manager for other reasons by >not including them in any alarm models. In addition, > >REPLACEMENT: >The Alarm MIB provides a means to determine whether a given notification is >not of interest to managers for purposes of alarm management by permitting >inspection of the alarm models. If no entries in the alarmModelTable could >match a particular notification, then that notification is not relevant to >the alarm models defined. In addition, > >Randy > > > > From exim@www1.ietf.org Fri Oct 17 14:35: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 OAA15162 for ; Fri, 17 Oct 2003 14:35:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZRI-0003hZ-5l for disman-archive@odin.ietf.org; Fri, 17 Oct 2003 14:35:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HIZ4r7014223 for disman-archive@odin.ietf.org; Fri, 17 Oct 2003 14:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZRH-0003hC-OF for disman-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 14:35:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15137 for ; Fri, 17 Oct 2003 14:34:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZRF-0006zE-00 for disman-web-archive@ietf.org; Fri, 17 Oct 2003 14:35:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAZRE-0006zB-00 for disman-web-archive@ietf.org; Fri, 17 Oct 2003 14:35:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZRF-0003gW-TQ; Fri, 17 Oct 2003 14:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZQJ-0003fh-Q3 for disman@optimus.ietf.org; Fri, 17 Oct 2003 14:34:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15115 for ; Fri, 17 Oct 2003 14:33:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZQ4-0006yf-00 for disman@ietf.org; Fri, 17 Oct 2003 14:33:48 -0400 Received: from colossus.systems.pipex.net ([62.241.160.73]) by ietf-mx with esmtp (Exim 4.12) id 1AAZQ4-0006yY-00 for disman@ietf.org; Fri, 17 Oct 2003 14:33:48 -0400 Received: from tom3 (1Cust85.tnt30.lnd3.gbr.da.uu.net [62.188.122.85]) by colossus.systems.pipex.net (Postfix) with SMTP id 6C65E16002C82; Fri, 17 Oct 2003 19:33:12 +0100 (BST) Message-ID: <001301c394dc$bba87040$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Sharon Chisholm" , "Disman (E-mail)" Subject: Re: [Disman] section 3.3.3 in draft-ietf-disman-alarm-mib-15.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 19:21:27 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I now find this harder to comprehend and no longer know whether I agree with it or not:-( Is it saying "The Alarm MIB allows a manager to specify which Notifications are of interest for the purposes of alarm management (by having entries for those Notifications in the alarmModelTable). If no entries in the alarmModelTable match a particular Notification, then that Notification plays no part in the defined alarm models. In addition,..." If so, I propose a text along these lines, stressing the positive aspects not the negative. If not, then I no longer understand. Tom Petch -----Original Message----- From: Sharon Chisholm To: Disman (E-mail) Date: 15 October 2003 18:04 Subject: RE: [Disman] section 3.3.3 in draft-ietf-disman-alarm-mib-15.txt >Hi > >The following is the proposed resolution to Randy-24 Assuming no objection, >this item will be considered closed conditional on the proposed edit being >done. > >In section 3.3.3, replace > >"The Alarm MIB provides a means to tell what Notifications are just >informational events or not of interest to the manager for other reasons by >not including them in any alarm models. In addition," > >With >"The Alarm MIB provides a means to determine whether a given notification is >not of interest to managers for purposes of alarm management by permitting >inspection of the alarm models. If no entries in the alarmModelTable could >match a particular notification, then that notification is not relevant to >the alarm models defined. In addition," > >Sharon > >-----Original Message----- >From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >Sent: Tuesday, October 07, 2003 2:43 PM >To: Disman (E-mail) >Subject: [Disman] section 3.3.3 in 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 >... >> 24) Section 3.3.3: the first sentence is a bit hard to swallow: >> as a practical matter, to find out which notifications are >> not of interest, one would have to walk the alarm model table >> to find out what *is* of interest, and then remove that set >> from the set of all possible notifications, which isn't listed >> in any convenient spot. >... > >Proposed fix: > >CURRENT: >The Alarm MIB provides a means to tell what Notifications are just >informational events or not of interest to the manager for other reasons by >not including them in any alarm models. In addition, > >REPLACEMENT: >The Alarm MIB provides a means to determine whether a given notification is >not of interest to managers for purposes of alarm management by permitting >inspection of the alarm models. If no entries in the alarmModelTable could >match a particular notification, then that notification is not relevant to >the alarm models defined. In addition, > >Randy > > > > From disman-admin@ietf.org Fri Oct 17 14:48: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 OAA15518 for ; Fri, 17 Oct 2003 14:48:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZdp-0004Gd-3z; Fri, 17 Oct 2003 14:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZd2-0004Fa-BY for disman@optimus.ietf.org; Fri, 17 Oct 2003 14:47:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15471 for ; Fri, 17 Oct 2003 14:47:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZcz-00074o-00 for disman@ietf.org; Fri, 17 Oct 2003 14:47:09 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AAZcz-00074l-00 for disman@ietf.org; Fri, 17 Oct 2003 14:47:09 -0400 Received: from h-68-164-80-100.snvacaid.dynamic.covad.net ([68.164.80.100] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AAZcx-0001ft-00 for disman@ietf.org; Fri, 17 Oct 2003 11:47:08 -0700 Message-ID: <006401c394df$24801ee0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <001301c394dc$bba87040$0301a8c0@tom3> Subject: Re: [Disman] section 3.3.3 in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 11:47:40 -0700 Hi - > From: "Tom Petch" > To: "Sharon Chisholm" ; "Disman (E-mail)" > Sent: Friday, October 17, 2003 11:21 AM > Subject: Re: [Disman] section 3.3.3 in draft-ietf-disman-alarm-mib-15.txt > > I now find this harder to comprehend and no longer know whether I > agree with it or not:-( > > Is it saying > > "The Alarm MIB allows a manager to specify which Notifications are of > interest for the purposes of alarm management (by having entries for > those Notifications in the alarmModelTable). If no entries in the > alarmModelTable match a particular Notification, then that > Notification plays no part in the defined alarm models. In > addition,..." > > If so, I propose a text along these lines, stressing the positive > aspects not the negative. ... That's fine with me. Randy From exim@www1.ietf.org Fri Oct 17 14:48:22 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 OAA15533 for ; Fri, 17 Oct 2003 14:48:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZdq-0004HP-LV for disman-archive@odin.ietf.org; Fri, 17 Oct 2003 14:48:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HIm2ea016445 for disman-archive@odin.ietf.org; Fri, 17 Oct 2003 14:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZdq-0004HA-Eu for disman-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 14:48:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15497 for ; Fri, 17 Oct 2003 14:47:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZdn-00074y-00 for disman-web-archive@ietf.org; Fri, 17 Oct 2003 14:47:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAZdn-00074v-00 for disman-web-archive@ietf.org; Fri, 17 Oct 2003 14:47:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZdp-0004Gd-3z; Fri, 17 Oct 2003 14:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZd2-0004Fa-BY for disman@optimus.ietf.org; Fri, 17 Oct 2003 14:47:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15471 for ; Fri, 17 Oct 2003 14:47:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZcz-00074o-00 for disman@ietf.org; Fri, 17 Oct 2003 14:47:09 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AAZcz-00074l-00 for disman@ietf.org; Fri, 17 Oct 2003 14:47:09 -0400 Received: from h-68-164-80-100.snvacaid.dynamic.covad.net ([68.164.80.100] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AAZcx-0001ft-00 for disman@ietf.org; Fri, 17 Oct 2003 11:47:08 -0700 Message-ID: <006401c394df$24801ee0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <001301c394dc$bba87040$0301a8c0@tom3> Subject: Re: [Disman] section 3.3.3 in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 11:47:40 -0700 Hi - > From: "Tom Petch" > To: "Sharon Chisholm" ; "Disman (E-mail)" > Sent: Friday, October 17, 2003 11:21 AM > Subject: Re: [Disman] section 3.3.3 in draft-ietf-disman-alarm-mib-15.txt > > I now find this harder to comprehend and no longer know whether I > agree with it or not:-( > > Is it saying > > "The Alarm MIB allows a manager to specify which Notifications are of > interest for the purposes of alarm management (by having entries for > those Notifications in the alarmModelTable). If no entries in the > alarmModelTable match a particular Notification, then that > Notification plays no part in the defined alarm models. In > addition,..." > > If so, I propose a text along these lines, stressing the positive > aspects not the negative. ... That's fine with me. Randy From disman-admin@ietf.org Sat Oct 18 12:16:24 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 MAA01902 for ; Sat, 18 Oct 2003 12:16:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAtkH-0001cw-PR; Sat, 18 Oct 2003 12:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAtk9-0001bb-3C for disman@optimus.ietf.org; Sat, 18 Oct 2003 12:15:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01873 for ; Sat, 18 Oct 2003 12:15:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAtk7-0002aJ-00 for disman@ietf.org; Sat, 18 Oct 2003 12:15:51 -0400 Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by ietf-mx with esmtp (Exim 4.12) id 1AAtk7-0002aD-00 for disman@ietf.org; Sat, 18 Oct 2003 12:15:51 -0400 Received: from h-69-3-241-62.snvacaid.dynamic.covad.net ([69.3.241.62] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AAtk4-0002NW-00 for disman@ietf.org; Sat, 18 Oct 2003 09:15:48 -0700 Message-ID: <001101c39593$2c37ee60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Fw: Sunday training classes at IETF58 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 18 Oct 2003 09:16:22 -0700 Hi - > From: "Avri Doria" > To: > Sent: Friday, October 17, 2003 4:08 AM > Subject: Sunday training classes at IETF58 > > In addition to the Newcomer's training and the security tutorial, the > IETF sunday training schedule for Minneapolis will include two new > sessions. > > The first covers the editor's role in working with the WG and in > producing RFCs. This is a completely new course. The session is open > to both current editors and folks who think they may be interested in > taking on an editorship, or co-editorship, at some point in the future. > > The second is the WG chairs training course. This is an extension of > the course that has been given during lunch sessions for WG chairs. > This session is open to both current WG chairs and to anyone who thinks > they may be interested in chairing a WG. > > The schedule for the courses is listed below. There is no need to > pre-register, just show up. > > Thanks > a. > > > Sunday, November 10, 2003 > ========================= > > 1330-1430 Newcomers Training -- Salon B (Scott Bradner) > > An introduction to the IETF for anyone who wants to know > more about the IETF, specifically recommended for all new > or recent IETF attendees. The session covers the IETF > history, structure, and standards process. It also > provides tips for success in the IETF environment. > > 1330-1500 Editor's Training -- Conrad C (Avri Doria) > > Training for current or aspiring IETF document > editors. Covers the roles and responsibilities > of a document editor, and includes advice on > producing a high-quality IETF specification. > > 1330-1500 Intro WG Chairs Training -- Conrad B (Margaret Wasserman) > > Introductory training for new or aspiring WG chairs. > Covers the role and responsibilities of the WG chair, > and includes advice on how to run a WG that is fair, > open and productive. > > 1500-1700 Security Tutorial -- Salon B (Radia Perlman) > > All IETF attendees need to be aware of the security > implications of our design choices. This session > offers a basic primer in protocol security, as well > as advice on how to write the Security Considerations > sections required for all IETF documents. > > > > From exim@www1.ietf.org Sat Oct 18 12:16: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 MAA01917 for ; Sat, 18 Oct 2003 12:16:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAtkL-0001dv-9d for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 12:16:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9IGG5u7006311 for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 12:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAtkL-0001di-4V for disman-web-archive@optimus.ietf.org; Sat, 18 Oct 2003 12:16:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01894 for ; Sat, 18 Oct 2003 12:15:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAtkJ-0002aW-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 12:16:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAtkJ-0002aT-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 12:16:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAtkH-0001cw-PR; Sat, 18 Oct 2003 12:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAtk9-0001bb-3C for disman@optimus.ietf.org; Sat, 18 Oct 2003 12:15:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01873 for ; Sat, 18 Oct 2003 12:15:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAtk7-0002aJ-00 for disman@ietf.org; Sat, 18 Oct 2003 12:15:51 -0400 Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by ietf-mx with esmtp (Exim 4.12) id 1AAtk7-0002aD-00 for disman@ietf.org; Sat, 18 Oct 2003 12:15:51 -0400 Received: from h-69-3-241-62.snvacaid.dynamic.covad.net ([69.3.241.62] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AAtk4-0002NW-00 for disman@ietf.org; Sat, 18 Oct 2003 09:15:48 -0700 Message-ID: <001101c39593$2c37ee60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Fw: Sunday training classes at IETF58 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 18 Oct 2003 09:16:22 -0700 Hi - > From: "Avri Doria" > To: > Sent: Friday, October 17, 2003 4:08 AM > Subject: Sunday training classes at IETF58 > > In addition to the Newcomer's training and the security tutorial, the > IETF sunday training schedule for Minneapolis will include two new > sessions. > > The first covers the editor's role in working with the WG and in > producing RFCs. This is a completely new course. The session is open > to both current editors and folks who think they may be interested in > taking on an editorship, or co-editorship, at some point in the future. > > The second is the WG chairs training course. This is an extension of > the course that has been given during lunch sessions for WG chairs. > This session is open to both current WG chairs and to anyone who thinks > they may be interested in chairing a WG. > > The schedule for the courses is listed below. There is no need to > pre-register, just show up. > > Thanks > a. > > > Sunday, November 10, 2003 > ========================= > > 1330-1430 Newcomers Training -- Salon B (Scott Bradner) > > An introduction to the IETF for anyone who wants to know > more about the IETF, specifically recommended for all new > or recent IETF attendees. The session covers the IETF > history, structure, and standards process. It also > provides tips for success in the IETF environment. > > 1330-1500 Editor's Training -- Conrad C (Avri Doria) > > Training for current or aspiring IETF document > editors. Covers the roles and responsibilities > of a document editor, and includes advice on > producing a high-quality IETF specification. > > 1330-1500 Intro WG Chairs Training -- Conrad B (Margaret Wasserman) > > Introductory training for new or aspiring WG chairs. > Covers the role and responsibilities of the WG chair, > and includes advice on how to run a WG that is fair, > open and productive. > > 1500-1700 Security Tutorial -- Salon B (Radia Perlman) > > All IETF attendees need to be aware of the security > implications of our design choices. This session > offers a basic primer in protocol security, as well > as advice on how to write the Security Considerations > sections required for all IETF documents. > > > > From disman-admin@ietf.org Sat Oct 18 13:58:22 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 NAA03863 for ; Sat, 18 Oct 2003 13:58:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAvKz-00036P-0Z; Sat, 18 Oct 2003 13:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAvKx-000368-0i for disman@optimus.ietf.org; Sat, 18 Oct 2003 13:57:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03856 for ; Sat, 18 Oct 2003 13:57:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAvKu-0003uB-00 for disman@ietf.org; Sat, 18 Oct 2003 13:57:56 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AAvKu-0003u2-00 for disman@ietf.org; Sat, 18 Oct 2003 13:57:56 -0400 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 h9IHvJG09934 for ; Sat, 18 Oct 2003 13:57:20 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WPGS>; Sat, 18 Oct 2003 13:57:20 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A895@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: Sat, 18 Oct 2003 13:57:18 -0400 Hi 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. 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. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 03, 2003 1:17 AM To: Disman (E-mail) Subject: [Disman] varbind offsets in alarm-mib-15 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 ... > 47) (alarmModelVarbindIndex) (also alarmActiveVariableEntry) I repeat > my comments from May, since they're still not reflected in the > draft: > > > The words that are there now seem to be backwards from what I > > thought was agreed: since RFC 3416 is Standard, and 1157 is > > Historic, that the numbering should start with 1 for the SysUptime, > > which would be the value extracted from elsewhere in the PDU in the > > case of a SNMPv1 trap. What's there now (still) seems unnecessarily > > confusing. > > > > Note that Harrie Hazewinkel's message of March 18, 2003 also has > > concerns with this same paragraph. > > > > The discussion back in April 22, 2002 went the same way, and > > Sharon's post of June 3, 2002 gave the resolution of issue #38 as > > being to treat everything "v2-style". > > Sharon-> See Section 3.6 of the document ... The text now reads: 3.6 Notification Varbind Storage and Reference In SNMPv1 [RFC1157], the varbinds in the Trap-PDU sent over the wire map one to one into those varbinds listed in the SMI of the trap in the MIB in which it was defined[RFC1215]. In the case of linkDown trap, the first varbind can unambiguously be identified as ifIndex. With the introduction of the InformRequest-PDU and SNMPv2-Trap-PDU types, which send sysUptime and snmpTrapOID as the first two varbinds, while the SMI in the MIB where the Notification is defined only lists additional varbinds, the meaning of "first varbind" becomes less clear. In the case of the linkDown Notification, referring to the first varbind could potentially be interpreted as either the sysUptime or ifIndex. The varbind storage approach taken in the Alarm MIB is that sysUptime and snmpTrapOID SHALL always be stored in the active alarm variable table as entry 1 and 2 respectively, regardless of whether the transport was the Trap-PDU, the InformRequest-PDU or the SNMPv2-Trap-PDU. If the incoming Notification is 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]. So far, so good. But then the next paragraph says: 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. This seems unnecessarily convoluted, and results in an even more complicated alarmModelVarbindIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The index into the varbind listing of the notification indicated by alarmModelNotificationId which helps signal that the given alarm has changed state. If there is no applicable varbind, the value of this object MUST be zero. 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." DEFVAL { 0 } ::= { alarmModelEntry 4 } As a technical contributor, I think it's really twisted to warp everything into an SNMPv1 point of view. 1 should refer to the first varbind in alarmActiveVariableTable for a particular alarm. This is also needed for internal consistency with the DESCRIPTION of alarmActiveVariableEntry, which states: If the incoming notification is instead an SNMPv1 Trap-PDU and the value of alarmModelVarbindIndex is 1 or 2, an appropriate value for sysUpTime.0 or snmpTrapOID.0 shall be determined by using the rules in section 3.1 of [RFC3584]." As WG chair, I thought we had a clear consensus to do it the SNMPv3 way. Randy From exim@www1.ietf.org Sat Oct 18 13:58: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 NAA03878 for ; Sat, 18 Oct 2003 13:58:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAvL1-00037Z-CK for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 13:58:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9IHw3Ca011991 for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 13:58:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAvL1-00037K-8T for disman-web-archive@optimus.ietf.org; Sat, 18 Oct 2003 13:58:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03860 for ; Sat, 18 Oct 2003 13:57:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAvKy-0003uH-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 13:58:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAvKy-0003uE-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 13:58:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAvKz-00036P-0Z; Sat, 18 Oct 2003 13:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAvKx-000368-0i for disman@optimus.ietf.org; Sat, 18 Oct 2003 13:57:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03856 for ; Sat, 18 Oct 2003 13:57:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAvKu-0003uB-00 for disman@ietf.org; Sat, 18 Oct 2003 13:57:56 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AAvKu-0003u2-00 for disman@ietf.org; Sat, 18 Oct 2003 13:57:56 -0400 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 h9IHvJG09934 for ; Sat, 18 Oct 2003 13:57:20 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WPGS>; Sat, 18 Oct 2003 13:57:20 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A895@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: Sat, 18 Oct 2003 13:57:18 -0400 Hi 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. 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. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 03, 2003 1:17 AM To: Disman (E-mail) Subject: [Disman] varbind offsets in alarm-mib-15 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 ... > 47) (alarmModelVarbindIndex) (also alarmActiveVariableEntry) I repeat > my comments from May, since they're still not reflected in the > draft: > > > The words that are there now seem to be backwards from what I > > thought was agreed: since RFC 3416 is Standard, and 1157 is > > Historic, that the numbering should start with 1 for the SysUptime, > > which would be the value extracted from elsewhere in the PDU in the > > case of a SNMPv1 trap. What's there now (still) seems unnecessarily > > confusing. > > > > Note that Harrie Hazewinkel's message of March 18, 2003 also has > > concerns with this same paragraph. > > > > The discussion back in April 22, 2002 went the same way, and > > Sharon's post of June 3, 2002 gave the resolution of issue #38 as > > being to treat everything "v2-style". > > Sharon-> See Section 3.6 of the document ... The text now reads: 3.6 Notification Varbind Storage and Reference In SNMPv1 [RFC1157], the varbinds in the Trap-PDU sent over the wire map one to one into those varbinds listed in the SMI of the trap in the MIB in which it was defined[RFC1215]. In the case of linkDown trap, the first varbind can unambiguously be identified as ifIndex. With the introduction of the InformRequest-PDU and SNMPv2-Trap-PDU types, which send sysUptime and snmpTrapOID as the first two varbinds, while the SMI in the MIB where the Notification is defined only lists additional varbinds, the meaning of "first varbind" becomes less clear. In the case of the linkDown Notification, referring to the first varbind could potentially be interpreted as either the sysUptime or ifIndex. The varbind storage approach taken in the Alarm MIB is that sysUptime and snmpTrapOID SHALL always be stored in the active alarm variable table as entry 1 and 2 respectively, regardless of whether the transport was the Trap-PDU, the InformRequest-PDU or the SNMPv2-Trap-PDU. If the incoming Notification is 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]. So far, so good. But then the next paragraph says: 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. This seems unnecessarily convoluted, and results in an even more complicated alarmModelVarbindIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The index into the varbind listing of the notification indicated by alarmModelNotificationId which helps signal that the given alarm has changed state. If there is no applicable varbind, the value of this object MUST be zero. 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." DEFVAL { 0 } ::= { alarmModelEntry 4 } As a technical contributor, I think it's really twisted to warp everything into an SNMPv1 point of view. 1 should refer to the first varbind in alarmActiveVariableTable for a particular alarm. This is also needed for internal consistency with the DESCRIPTION of alarmActiveVariableEntry, which states: If the incoming notification is instead an SNMPv1 Trap-PDU and the value of alarmModelVarbindIndex is 1 or 2, an appropriate value for sysUpTime.0 or snmpTrapOID.0 shall be determined by using the rules in section 3.1 of [RFC3584]." As WG chair, I thought we had a clear consensus to do it the SNMPv3 way. Randy From disman-admin@ietf.org Sat Oct 18 16:33: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 QAA08690 for ; Sat, 18 Oct 2003 16:33:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAxkz-0001LE-Bj; Sat, 18 Oct 2003 16:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAxkR-0001GO-51 for disman@optimus.ietf.org; Sat, 18 Oct 2003 16:32:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08666 for ; Sat, 18 Oct 2003 16:32:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAxkP-0006Ro-00 for disman@ietf.org; Sat, 18 Oct 2003 16:32:25 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AAxkO-0006RM-00 for disman@ietf.org; Sat, 18 Oct 2003 16:32:24 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9IKVmE26180 for ; Sat, 18 Oct 2003 16:31:48 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WP7T>; Sat, 18 Oct 2003 16:31:48 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8B7@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: Sat, 18 Oct 2003 16:31:48 -0400 Hi Again, this is the trade-off that made sense when we last discussed the problem. Allowing deletion of models with active alarm instances leaves orphaned active alarms. Not allowing it makes it more difficult to delete the alarm models. There would be three possible ways to address the concern - Add new instrumentation to manage emergency killing of alarms - Allow deletion of alarm models at any time, but force the clean up of any of their active alarms - Keep exactly as is and make a note in the security considerations. I'd like to take the first one off the table as both over engineering and too big of a change to make at this point. The second one makes me a bit nervous but I think I could live with it. I suspect one or more of Randy's hats would object to the third. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 1:43 PM To: Disman (E-mail) Subject: Re: [Disman] unthrottleable alarm state change notifications Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 5:51 AM > Subject: RE: [Disman] unthrottleable alarm state change notifications ... > It was design intent to prevent the deletion of alarm models while > there were active alarms using that model. ... Is no one else bothered by the behavior this design produces? - manager (mistakenly) creates alarm model that matches some frequent event from a large number of sources (e.g., process creation or connection attempt) - zillions of alarms are created - manager, realizing mistake, can't shut it down: - cannot modify alarmModelEntry attributes to correct mistake - cannot delete alarmModelEntry - the alarm model entry persists, so even re-booting the system won't fix the problem There's an even simpler failure mode: - manager creates an alarm model, but the "clear" entry refers to an event that will never happen, perhaps due to a typo, or perhaps due to the way the managed system works - one (or more alarms) created - there is no way to clear these alarms - there is no way to get rid of the erroneous alarm model If this is really what the WG wants, the chair will let it go, but this technical contributor thinks its a big mistake. If there's an error in my reasoning here, please elucidate. Randy From exim@www1.ietf.org Sat Oct 18 16:33:28 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 QAA08705 for ; Sat, 18 Oct 2003 16:33:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAxl6-0001MT-2y for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 16:33:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9IKX8YN005229 for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 16:33:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAxl5-0001MG-Vv for disman-web-archive@optimus.ietf.org; Sat, 18 Oct 2003 16:33:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08683 for ; Sat, 18 Oct 2003 16:32:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAxl3-0006SP-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 16:33:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAxl3-0006SL-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 16:33:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAxkz-0001LE-Bj; Sat, 18 Oct 2003 16:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAxkR-0001GO-51 for disman@optimus.ietf.org; Sat, 18 Oct 2003 16:32:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08666 for ; Sat, 18 Oct 2003 16:32:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAxkP-0006Ro-00 for disman@ietf.org; Sat, 18 Oct 2003 16:32:25 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AAxkO-0006RM-00 for disman@ietf.org; Sat, 18 Oct 2003 16:32:24 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9IKVmE26180 for ; Sat, 18 Oct 2003 16:31:48 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WP7T>; Sat, 18 Oct 2003 16:31:48 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8B7@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: Sat, 18 Oct 2003 16:31:48 -0400 Hi Again, this is the trade-off that made sense when we last discussed the problem. Allowing deletion of models with active alarm instances leaves orphaned active alarms. Not allowing it makes it more difficult to delete the alarm models. There would be three possible ways to address the concern - Add new instrumentation to manage emergency killing of alarms - Allow deletion of alarm models at any time, but force the clean up of any of their active alarms - Keep exactly as is and make a note in the security considerations. I'd like to take the first one off the table as both over engineering and too big of a change to make at this point. The second one makes me a bit nervous but I think I could live with it. I suspect one or more of Randy's hats would object to the third. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 1:43 PM To: Disman (E-mail) Subject: Re: [Disman] unthrottleable alarm state change notifications Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 5:51 AM > Subject: RE: [Disman] unthrottleable alarm state change notifications ... > It was design intent to prevent the deletion of alarm models while > there were active alarms using that model. ... Is no one else bothered by the behavior this design produces? - manager (mistakenly) creates alarm model that matches some frequent event from a large number of sources (e.g., process creation or connection attempt) - zillions of alarms are created - manager, realizing mistake, can't shut it down: - cannot modify alarmModelEntry attributes to correct mistake - cannot delete alarmModelEntry - the alarm model entry persists, so even re-booting the system won't fix the problem There's an even simpler failure mode: - manager creates an alarm model, but the "clear" entry refers to an event that will never happen, perhaps due to a typo, or perhaps due to the way the managed system works - one (or more alarms) created - there is no way to clear these alarms - there is no way to get rid of the erroneous alarm model If this is really what the WG wants, the chair will let it go, but this technical contributor thinks its a big mistake. If there's an error in my reasoning here, please elucidate. Randy From disman-admin@ietf.org Sat Oct 18 17:46: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 RAA09991 for ; Sat, 18 Oct 2003 17:46:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAyte-0001hn-Ec; Sat, 18 Oct 2003 17:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAytP-0001cR-Hp for disman@optimus.ietf.org; Sat, 18 Oct 2003 17:45:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09977 for ; Sat, 18 Oct 2003 17:45:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAytM-0007AS-00 for disman@ietf.org; Sat, 18 Oct 2003 17:45:44 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AAytM-0007AJ-00 for disman@ietf.org; Sat, 18 Oct 2003 17:45:44 -0400 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 h9ILjDG15736 for ; Sat, 18 Oct 2003 17:45:13 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WQD5>; Sat, 18 Oct 2003 17:45:13 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8C1@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] alarmListName implications 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: Sat, 18 Oct 2003 17:45:12 -0400 Hi The following is the proposed resolution to Randy-56 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the description of alarmListName replace " The name of the list of alarms. This SHOULD be the same as nlmLogName if the Notification Log MIB [RFC3014] is supported. An implementation may allow multiple named alarm lists, up to some implementation-specific limit (which may be none). A zero-length list name is reserved for creation and deletion by the managed system, and MUST be used as the default log name by systems that do not support named alarm lists." With " The name of the list of alarms. This SHOULD be the same as nlmLogName if the Notification Log MIB [RFC3014] is supported. This SHOULD be the same as, or contain as a prefix, the applicable snmpNotifyFilterProfileName if the SNMP-NOTIFICATION-MIB DEFINITIONS [RFC3413] is supported. An implementation may allow multiple named alarm lists, up to some implementation-specific limit (which may be none). A zero-length list name is reserved for creation and deletion by the managed system, and MUST be used as the default log name by systems that do not support named alarm lists." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 3:06 PM To: Disman (E-mail) Subject: [Disman] alarmListName implications 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 ... > 56) alarmListName's DESCRIPTION should spell how this object's > value hooks into the SNMP-NOTIFICATION-MIB. Without out this > bit of explanation, the whole thing is magic. It's good that it explains the non-normative relationship to nlmLogName. However, it's more important that it also be explicit about the fact that the notification got here by matching an RFC 3413 snmpNotifyFilterProfileName, since that's the mechanism for selecting the notifications in the first place, as sketched out in the diagram in section 3.2 Randy From exim@www1.ietf.org Sat Oct 18 17:46: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 RAA10006 for ; Sat, 18 Oct 2003 17:46:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAytj-0001jG-0f for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 17:46:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ILk6hf006640 for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 17:46:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAyti-0001j1-Tq for disman-web-archive@optimus.ietf.org; Sat, 18 Oct 2003 17:46:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09987 for ; Sat, 18 Oct 2003 17:45:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAytg-0007Ae-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 17:46:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAytf-0007Ab-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 17:46:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAyte-0001hn-Ec; Sat, 18 Oct 2003 17:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAytP-0001cR-Hp for disman@optimus.ietf.org; Sat, 18 Oct 2003 17:45:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09977 for ; Sat, 18 Oct 2003 17:45:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAytM-0007AS-00 for disman@ietf.org; Sat, 18 Oct 2003 17:45:44 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AAytM-0007AJ-00 for disman@ietf.org; Sat, 18 Oct 2003 17:45:44 -0400 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 h9ILjDG15736 for ; Sat, 18 Oct 2003 17:45:13 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WQD5>; Sat, 18 Oct 2003 17:45:13 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8C1@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] alarmListName implications 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: Sat, 18 Oct 2003 17:45:12 -0400 Hi The following is the proposed resolution to Randy-56 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the description of alarmListName replace " The name of the list of alarms. This SHOULD be the same as nlmLogName if the Notification Log MIB [RFC3014] is supported. An implementation may allow multiple named alarm lists, up to some implementation-specific limit (which may be none). A zero-length list name is reserved for creation and deletion by the managed system, and MUST be used as the default log name by systems that do not support named alarm lists." With " The name of the list of alarms. This SHOULD be the same as nlmLogName if the Notification Log MIB [RFC3014] is supported. This SHOULD be the same as, or contain as a prefix, the applicable snmpNotifyFilterProfileName if the SNMP-NOTIFICATION-MIB DEFINITIONS [RFC3413] is supported. An implementation may allow multiple named alarm lists, up to some implementation-specific limit (which may be none). A zero-length list name is reserved for creation and deletion by the managed system, and MUST be used as the default log name by systems that do not support named alarm lists." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 3:06 PM To: Disman (E-mail) Subject: [Disman] alarmListName implications 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 ... > 56) alarmListName's DESCRIPTION should spell how this object's > value hooks into the SNMP-NOTIFICATION-MIB. Without out this > bit of explanation, the whole thing is magic. It's good that it explains the non-normative relationship to nlmLogName. However, it's more important that it also be explicit about the fact that the notification got here by matching an RFC 3413 snmpNotifyFilterProfileName, since that's the mechanism for selecting the notifications in the first place, as sketched out in the diagram in section 3.2 Randy From disman-admin@ietf.org Sat Oct 18 18:02: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 SAA10410 for ; Sat, 18 Oct 2003 18:02:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAz96-0003QR-Oc; Sat, 18 Oct 2003 18:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAz8P-0003N6-I9 for disman@optimus.ietf.org; Sat, 18 Oct 2003 18:01:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10385 for ; Sat, 18 Oct 2003 18:01:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAz8M-0007IE-00 for disman@ietf.org; Sat, 18 Oct 2003 18:01:14 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AAz8L-0007I2-00 for disman@ietf.org; Sat, 18 Oct 2003 18:01:13 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9IM0fE00906 for ; Sat, 18 Oct 2003 18:00:41 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WQFT>; Sat, 18 Oct 2003 18:00:41 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8C8@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] alarmActiveEngineAddress 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: Sat, 18 Oct 2003 18:00:40 -0400 Hi The following is the proposed resolution to Randy-58 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the description for alarmActiveEngineAddress, replace "The Address of the SNMP engine on which the alarm is occurring. This is used to identify the source of an SNMPv1 trap, since an alarmActiveEngineId cannot be extracted from the SNMPv1 trap PDU. This object MUST always be instantiated, even if the list can contain alarms from only one engine."" With "The address of the SNMP engine on which the alarm is occurring. This object MUST always be instantiated, even if the list can contain alarms from only one engine." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 3:14 PM To: Disman (E-mail) Subject: Re: [Disman] alarmActiveEngineAddress Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 11:18 AM > Subject: RE: [Disman] alarmActiveEngineAddress ... > No change will be done to address the second observation. The Engine > ID object indicates that it identifies the source of the alarm and > this indicates it is used when that isn't available. ... But that's not what the description says. The sentence "This is used to identify the source of an SNMPv1 trap, since an alarmActiveEngineId cannot be extracted from the SNMPv1 trap PDU." is still wrong. Even if one has an EngineId, one *still* needs an address to get there. Proposed replacement: Delete the sentence. Randy From exim@www1.ietf.org Sat Oct 18 18:02:22 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 SAA10425 for ; Sat, 18 Oct 2003 18:02:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAz98-0003RM-VM for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 18:02:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9IM22BH013224 for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 18:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAz98-0003RD-Rm for disman-web-archive@optimus.ietf.org; Sat, 18 Oct 2003 18:02:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10396 for ; Sat, 18 Oct 2003 18:01:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAz95-0007IV-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 18:02:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAz95-0007IS-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 18:01:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAz96-0003QR-Oc; Sat, 18 Oct 2003 18:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAz8P-0003N6-I9 for disman@optimus.ietf.org; Sat, 18 Oct 2003 18:01:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10385 for ; Sat, 18 Oct 2003 18:01:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAz8M-0007IE-00 for disman@ietf.org; Sat, 18 Oct 2003 18:01:14 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AAz8L-0007I2-00 for disman@ietf.org; Sat, 18 Oct 2003 18:01:13 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9IM0fE00906 for ; Sat, 18 Oct 2003 18:00:41 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WQFT>; Sat, 18 Oct 2003 18:00:41 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8C8@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] alarmActiveEngineAddress 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: Sat, 18 Oct 2003 18:00:40 -0400 Hi The following is the proposed resolution to Randy-58 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In the description for alarmActiveEngineAddress, replace "The Address of the SNMP engine on which the alarm is occurring. This is used to identify the source of an SNMPv1 trap, since an alarmActiveEngineId cannot be extracted from the SNMPv1 trap PDU. This object MUST always be instantiated, even if the list can contain alarms from only one engine."" With "The address of the SNMP engine on which the alarm is occurring. This object MUST always be instantiated, even if the list can contain alarms from only one engine." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 3:14 PM To: Disman (E-mail) Subject: Re: [Disman] alarmActiveEngineAddress Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Cc: "Randy Presuhn" > Sent: Wednesday, October 08, 2003 11:18 AM > Subject: RE: [Disman] alarmActiveEngineAddress ... > No change will be done to address the second observation. The Engine > ID object indicates that it identifies the source of the alarm and > this indicates it is used when that isn't available. ... But that's not what the description says. The sentence "This is used to identify the source of an SNMPv1 trap, since an alarmActiveEngineId cannot be extracted from the SNMPv1 trap PDU." is still wrong. Even if one has an EngineId, one *still* needs an address to get there. Proposed replacement: Delete the sentence. Randy From disman-admin@ietf.org Sat Oct 18 18:16: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 SAA11801 for ; Sat, 18 Oct 2003 18:16:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAzMe-0006ts-VL; Sat, 18 Oct 2003 18:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAzMG-0006qp-9i for disman@optimus.ietf.org; Sat, 18 Oct 2003 18:15:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11668 for ; Sat, 18 Oct 2003 18:15:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAzMD-0007Qh-00 for disman@ietf.org; Sat, 18 Oct 2003 18:15:33 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AAzMC-0007Qa-00 for disman@ietf.org; Sat, 18 Oct 2003 18:15:32 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9IMF2E01138 for ; Sat, 18 Oct 2003 18:15:02 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WQHB>; Sat, 18 Oct 2003 18:15:02 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8CC@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: Sat, 18 Oct 2003 18:15:01 -0400 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 Sat Oct 18 18:16: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 SAA11819 for ; Sat, 18 Oct 2003 18:16:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAzMg-0006uy-Rx for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 18:16:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9IMG2BA026586 for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 18:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAzMg-0006uj-Lq for disman-web-archive@optimus.ietf.org; Sat, 18 Oct 2003 18:16:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11720 for ; Sat, 18 Oct 2003 18:15:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAzMd-0007RF-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 18:15:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAzMd-0007RA-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 18:15:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAzMe-0006ts-VL; Sat, 18 Oct 2003 18:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAzMG-0006qp-9i for disman@optimus.ietf.org; Sat, 18 Oct 2003 18:15:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11668 for ; Sat, 18 Oct 2003 18:15:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAzMD-0007Qh-00 for disman@ietf.org; Sat, 18 Oct 2003 18:15:33 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AAzMC-0007Qa-00 for disman@ietf.org; Sat, 18 Oct 2003 18:15:32 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9IMF2E01138 for ; Sat, 18 Oct 2003 18:15:02 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WQHB>; Sat, 18 Oct 2003 18:15:02 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8CC@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: Sat, 18 Oct 2003 18:15:01 -0400 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 Sat Oct 18 18:21: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 SAA12161 for ; Sat, 18 Oct 2003 18:21:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAzRV-0000AY-Pj; Sat, 18 Oct 2003 18:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAzRG-000070-8X for disman@optimus.ietf.org; Sat, 18 Oct 2003 18:20:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12150 for ; Sat, 18 Oct 2003 18:20:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAzRD-0007Wh-00 for disman@ietf.org; Sat, 18 Oct 2003 18:20:43 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AAzRC-0007WQ-00 for disman@ietf.org; Sat, 18 Oct 2003 18:20:42 -0400 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 h9IMKCG16700 for ; Sat, 18 Oct 2003 18:20:12 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WQHV>; Sat, 18 Oct 2003 18:20:12 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8CD@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] alarmListName implications 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: Sat, 18 Oct 2003 18:20:11 -0400 Hi The following is the proposed resolution to Randy-60. Assuming no objection, this item will is closed with no changes to the draft. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 3:06 PM To: Disman (E-mail) Subject: [Disman] alarmListName implications 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 ... > 60) alarmActiveLogPointer: should spell out that the log's name > would be the same as alarmListName for this instance. > ditto alarmClearLogIndex I'll relent on this one, since adequate text for (56) would make this redundant. Randy From exim@www1.ietf.org Sat Oct 18 18:21:22 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 SAA12175 for ; Sat, 18 Oct 2003 18:21:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAzRX-0000BV-Ai for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 18:21:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9IML3qK000702 for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 18:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAzRX-0000BF-4D for disman-web-archive@optimus.ietf.org; Sat, 18 Oct 2003 18:21:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12155 for ; Sat, 18 Oct 2003 18:20:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAzRU-0007Wt-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 18:21:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAzRT-0007Wq-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 18:20:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAzRV-0000AY-Pj; Sat, 18 Oct 2003 18:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAzRG-000070-8X for disman@optimus.ietf.org; Sat, 18 Oct 2003 18:20:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12150 for ; Sat, 18 Oct 2003 18:20:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAzRD-0007Wh-00 for disman@ietf.org; Sat, 18 Oct 2003 18:20:43 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AAzRC-0007WQ-00 for disman@ietf.org; Sat, 18 Oct 2003 18:20:42 -0400 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 h9IMKCG16700 for ; Sat, 18 Oct 2003 18:20:12 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WQHV>; Sat, 18 Oct 2003 18:20:12 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8CD@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] alarmListName implications 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: Sat, 18 Oct 2003 18:20:11 -0400 Hi The following is the proposed resolution to Randy-60. Assuming no objection, this item will is closed with no changes to the draft. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 3:06 PM To: Disman (E-mail) Subject: [Disman] alarmListName implications 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 ... > 60) alarmActiveLogPointer: should spell out that the log's name > would be the same as alarmListName for this instance. > ditto alarmClearLogIndex I'll relent on this one, since adequate text for (56) would make this redundant. Randy From disman-admin@ietf.org Sat Oct 18 18:34: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 SAA12439 for ; Sat, 18 Oct 2003 18:34:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAze5-0003ES-2b; Sat, 18 Oct 2003 18:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAzdV-0002zT-HS for disman@optimus.ietf.org; Sat, 18 Oct 2003 18:33:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12418 for ; Sat, 18 Oct 2003 18:33:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAzdS-0007cf-00 for disman@ietf.org; Sat, 18 Oct 2003 18:33:22 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AAzdR-0007cK-00 for disman@ietf.org; Sat, 18 Oct 2003 18:33:21 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9IMWpE01476 for ; Sat, 18 Oct 2003 18:32:51 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WQ24>; Sat, 18 Oct 2003 18:32:51 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8D2@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: Sat, 18 Oct 2003 18:32:50 -0400 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: Friday, October 10, 2003 11:51 PM To: Disman (E-mail) Subject: Re: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Friday, October 10, 2003 11:59 AM > Subject: RE: [Disman] Section 5.1 in > draft-ietf-disman-alarm-mib-15.txt > > Hi > > For every A, there is a B. For every B there is an A. Therefore the # > of A = # of B. QED. ... Wrong. The current language says for every B there is an A. It does NOT say that for every A there is a B. Furthermore, if it did, then only ONE extension MIB could exist in a system, due to the way alarmModelSpecificPointer works. If someone defined a DMTF-ALARM-MIB, it could not under your reasoning exist in a system that also supported the ITU alarm stuff. Randy From exim@www1.ietf.org Sat Oct 18 18:34: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 SAA12454 for ; Sat, 18 Oct 2003 18:34:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAze6-0003Gh-Jq for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 18:34:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9IMY2VP012507 for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 18:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAze6-0003Fc-C6 for disman-web-archive@optimus.ietf.org; Sat, 18 Oct 2003 18:34:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12435 for ; Sat, 18 Oct 2003 18:33:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAze3-0007d8-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 18:33:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAze2-0007d5-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 18:33:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAze5-0003ES-2b; Sat, 18 Oct 2003 18:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAzdV-0002zT-HS for disman@optimus.ietf.org; Sat, 18 Oct 2003 18:33:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12418 for ; Sat, 18 Oct 2003 18:33:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAzdS-0007cf-00 for disman@ietf.org; Sat, 18 Oct 2003 18:33:22 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AAzdR-0007cK-00 for disman@ietf.org; Sat, 18 Oct 2003 18:33:21 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9IMWpE01476 for ; Sat, 18 Oct 2003 18:32:51 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WQ24>; Sat, 18 Oct 2003 18:32:51 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8D2@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: Sat, 18 Oct 2003 18:32:50 -0400 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: Friday, October 10, 2003 11:51 PM To: Disman (E-mail) Subject: Re: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Friday, October 10, 2003 11:59 AM > Subject: RE: [Disman] Section 5.1 in > draft-ietf-disman-alarm-mib-15.txt > > Hi > > For every A, there is a B. For every B there is an A. Therefore the # > of A = # of B. QED. ... Wrong. The current language says for every B there is an A. It does NOT say that for every A there is a B. Furthermore, if it did, then only ONE extension MIB could exist in a system, due to the way alarmModelSpecificPointer works. If someone defined a DMTF-ALARM-MIB, it could not under your reasoning exist in a system that also supported the ITU alarm stuff. Randy From disman-admin@ietf.org Sat Oct 18 19:11:34 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 TAA13206 for ; Sat, 18 Oct 2003 19:11:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0Dt-0005jP-V5; Sat, 18 Oct 2003 19:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0Di-0005ho-9y for disman@optimus.ietf.org; Sat, 18 Oct 2003 19:10:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13180 for ; Sat, 18 Oct 2003 19:10:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AB0Dd-00004m-00 for disman@ietf.org; Sat, 18 Oct 2003 19:10:45 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AB0Dc-000041-00 for disman@ietf.org; Sat, 18 Oct 2003 19:10:44 -0400 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 h9INAEG17772 for ; Sat, 18 Oct 2003 19:10:14 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WQMM>; Sat, 18 Oct 2003 19:10:14 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8D8@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] alarmListName implications 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: Sat, 18 Oct 2003 19:10:13 -0400 Hi The following is the proposed resolution to Randy-75-1 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: "This MIB module can provide access to information that may also be accessed through manipulation of the SNMP-NOTIFICATION-MIB and the NOTIFICATION-LOG-MIB. This is expressed in part through the common indexing structure of nlmLogName [RFC3014], snmpNotifyFilterProfileName [RFC3413], and alarmListName. Consequently, it is RECOMMENDED that security administrators take care to configure a coherent VACM security policy. The objects alarmActiveLogPointer, alarmActiveModelPointer, alarmActiveSpecificPointer, and alarmClearModelPointer are object identifiers that reference information to which a particular user might not be given direct access. The structure of these object identifiers does not permit the extraction of any sensitive information. Two other objects, alarmClearResourceId, and alarmActiveResourceId, are also syntactically object identifiers, but their structure could provide a user with potentially useful information to which he or she might not otherwise be granted access, such as the existence of a particular resource." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 3:06 PM To: Disman (E-mail) Subject: [Disman] alarmListName implications 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 ... > 75-1) Section 7 should describe the need for security administrators > to configure a coherent VACM policy for the configuration of the > SNMP-NOTIFICATION-MIB, the log MIB, and these MIBs based on log name. > > Sharon->We agreed back when everyone was complaining about the > Sharon->notification log MIB to not tie this document to it. The goal agree we don't need a normative reference > Sharon->was to be able to support it and any other log. ... That wasn't the reasoning as I recall it. The problem was that the initial versions of this tied alarms to log entries, and the life-cycle of a log entry may be different from that of an alarm. Anway, that's not the issue. This is *not* a question of making a normative reference to the log MIB. Rather, it's about explaining how this MIB is meant to be used. We've seen enough complaints that I'd prefer to err on the side of being overly clear. The relationship between RFC 3014's nlmLogName and RFC 3413's snmpNotifyFilterProfileName (particularly since 3014 calls it snmpNotifyFilterName) is practically an FAQ, even though 3014 2.2.1 spells it out. The -15- i-d only hints at the relationship in the diagram in section 3.2 For item 75-1, the issues are similar to those we faced when we did the log MIB: how to design the MIB and write the security considerations section so that we didn't "leak" information. To me, this means providing a modicum of guidance to security administrators in the security considerations section so that this MIB can be used with reasonable safety. The relationship between nlmLogName, snmpNotifyFilterProfileName, and alarmListName is deliberately chosen to make life easier for the security administrator. Proposed words to add to security considerations: "This MIB module can provide access to information that may also be accessed through manipulation of the SNMP-NOTIFICATION-MIB and the NOTIFICATION-LOG-MIB. This is expressed in part through the common indexing structure of nlmLogName [RFC3014], snmpNotifyFilterProfileName [RFC3413], and alarmListName. Consequently, it is RECOMMENDED that security administrators take care to configure a coherent VACM security policy. The objects alarmActiveLogPointer, alarmActiveModelPointer, alarmActiveSpecificPointer, and alarmClearModelPointer are object identifiers that reference information to which a particular user might not be given direct access. The structure of these object identifiers does not permit the extraction of any sensitive information. Two other objects, alarmClearResourceId, and alarmActiveResourceId, are also syntactically object identifiers, but their structure could provide a user with potentially useful information to which he or she might not otherwise be granted access, such as the existence of a particular resource." Whew. Randy From exim@www1.ietf.org Sat Oct 18 19:11:48 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 TAA13222 for ; Sat, 18 Oct 2003 19:11:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0EL-0005q1-U3 for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 19:11:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9INBTeE022438 for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 19:11:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0EL-0005pp-O3 for disman-web-archive@optimus.ietf.org; Sat, 18 Oct 2003 19:11:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13187 for ; Sat, 18 Oct 2003 19:10:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AB0Dw-00004v-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 19:11:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AB0Dv-00004s-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 19:11:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0Dt-0005jP-V5; Sat, 18 Oct 2003 19:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0Di-0005ho-9y for disman@optimus.ietf.org; Sat, 18 Oct 2003 19:10:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13180 for ; Sat, 18 Oct 2003 19:10:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AB0Dd-00004m-00 for disman@ietf.org; Sat, 18 Oct 2003 19:10:45 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AB0Dc-000041-00 for disman@ietf.org; Sat, 18 Oct 2003 19:10:44 -0400 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 h9INAEG17772 for ; Sat, 18 Oct 2003 19:10:14 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WQMM>; Sat, 18 Oct 2003 19:10:14 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8D8@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] alarmListName implications 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: Sat, 18 Oct 2003 19:10:13 -0400 Hi The following is the proposed resolution to Randy-75-1 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: "This MIB module can provide access to information that may also be accessed through manipulation of the SNMP-NOTIFICATION-MIB and the NOTIFICATION-LOG-MIB. This is expressed in part through the common indexing structure of nlmLogName [RFC3014], snmpNotifyFilterProfileName [RFC3413], and alarmListName. Consequently, it is RECOMMENDED that security administrators take care to configure a coherent VACM security policy. The objects alarmActiveLogPointer, alarmActiveModelPointer, alarmActiveSpecificPointer, and alarmClearModelPointer are object identifiers that reference information to which a particular user might not be given direct access. The structure of these object identifiers does not permit the extraction of any sensitive information. Two other objects, alarmClearResourceId, and alarmActiveResourceId, are also syntactically object identifiers, but their structure could provide a user with potentially useful information to which he or she might not otherwise be granted access, such as the existence of a particular resource." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, October 08, 2003 3:06 PM To: Disman (E-mail) Subject: [Disman] alarmListName implications 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 ... > 75-1) Section 7 should describe the need for security administrators > to configure a coherent VACM policy for the configuration of the > SNMP-NOTIFICATION-MIB, the log MIB, and these MIBs based on log name. > > Sharon->We agreed back when everyone was complaining about the > Sharon->notification log MIB to not tie this document to it. The goal agree we don't need a normative reference > Sharon->was to be able to support it and any other log. ... That wasn't the reasoning as I recall it. The problem was that the initial versions of this tied alarms to log entries, and the life-cycle of a log entry may be different from that of an alarm. Anway, that's not the issue. This is *not* a question of making a normative reference to the log MIB. Rather, it's about explaining how this MIB is meant to be used. We've seen enough complaints that I'd prefer to err on the side of being overly clear. The relationship between RFC 3014's nlmLogName and RFC 3413's snmpNotifyFilterProfileName (particularly since 3014 calls it snmpNotifyFilterName) is practically an FAQ, even though 3014 2.2.1 spells it out. The -15- i-d only hints at the relationship in the diagram in section 3.2 For item 75-1, the issues are similar to those we faced when we did the log MIB: how to design the MIB and write the security considerations section so that we didn't "leak" information. To me, this means providing a modicum of guidance to security administrators in the security considerations section so that this MIB can be used with reasonable safety. The relationship between nlmLogName, snmpNotifyFilterProfileName, and alarmListName is deliberately chosen to make life easier for the security administrator. Proposed words to add to security considerations: "This MIB module can provide access to information that may also be accessed through manipulation of the SNMP-NOTIFICATION-MIB and the NOTIFICATION-LOG-MIB. This is expressed in part through the common indexing structure of nlmLogName [RFC3014], snmpNotifyFilterProfileName [RFC3413], and alarmListName. Consequently, it is RECOMMENDED that security administrators take care to configure a coherent VACM security policy. The objects alarmActiveLogPointer, alarmActiveModelPointer, alarmActiveSpecificPointer, and alarmClearModelPointer are object identifiers that reference information to which a particular user might not be given direct access. The structure of these object identifiers does not permit the extraction of any sensitive information. Two other objects, alarmClearResourceId, and alarmActiveResourceId, are also syntactically object identifiers, but their structure could provide a user with potentially useful information to which he or she might not otherwise be granted access, such as the existence of a particular resource." Whew. Randy From disman-admin@ietf.org Sat Oct 18 19:22: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 TAA13454 for ; Sat, 18 Oct 2003 19:22:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0OW-0000PW-T6; Sat, 18 Oct 2003 19:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0OA-0000MG-71 for disman@optimus.ietf.org; Sat, 18 Oct 2003 19:21:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13440 for ; Sat, 18 Oct 2003 19:21:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AB0O8-0000BU-00 for disman@ietf.org; Sat, 18 Oct 2003 19:21:36 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AB0O7-0000BP-00 for disman@ietf.org; Sat, 18 Oct 2003 19:21:35 -0400 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 h9INL5G17938 for ; Sat, 18 Oct 2003 19:21:05 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WQ3K>; Sat, 18 Oct 2003 19:21:05 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8D9@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: Sat, 18 Oct 2003 19:21:04 -0400 Hi Ok. I don't understand your issue. There is no maximum because alarms MUST stay in the table while they are active. There is no wrapping because one of the indices is DataAndTime so therefore always increasing (unless I'm missing something). Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Saturday, October 11, 2003 12:03 AM To: Disman (E-mail) Subject: Re: [Disman] "table wrapping" in alarm MIB -15- Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Friday, October 10, 2003 11:18 AM > Subject: RE: [Disman] "table wrapping" in alarm MIB -15- ... > The following is the proposed resolution to Randy-74-4. Assuming no > objection, this item will is closed with no changes to the draft. > > In the definition of alarmActiveEntry is > " > "Entries appear in this table when alarms are raised. They > are removed when the alarm is cleared." > > One of the indices into this table is DataAndTime object. This table > therefore will not wrap, so discussing what happens when the table > wraps does not make sense. The statement that indicates that entries > are removed when the alarm is cleared implies that entries stay in the > table while they are active. End of story. ... Sorry, it's not. Please re-read my original comment: > > 75-4) I missed anything like an "alarmActiveMaximum", yet the > > document doesn't seem to describe what should happen if there are > > too many active alarms, as might happen if there are lots of > > instances of a particular type of resource, and an administrator > > inadvertently specifies a frequent, innocuous event as being of > > interest. ... The issue still stands. Randy From exim@www1.ietf.org Sat Oct 18 19:22:22 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 TAA13469 for ; Sat, 18 Oct 2003 19:22:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0OY-0000Qo-8c for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 19:22:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9INM2sX001652 for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 19:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0OY-0000QZ-5C for disman-web-archive@optimus.ietf.org; Sat, 18 Oct 2003 19:22:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13451 for ; Sat, 18 Oct 2003 19:21:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AB0OW-0000Bn-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 19:22:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AB0OW-0000Bk-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 19:22:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0OW-0000PW-T6; Sat, 18 Oct 2003 19:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0OA-0000MG-71 for disman@optimus.ietf.org; Sat, 18 Oct 2003 19:21:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13440 for ; Sat, 18 Oct 2003 19:21:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AB0O8-0000BU-00 for disman@ietf.org; Sat, 18 Oct 2003 19:21:36 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AB0O7-0000BP-00 for disman@ietf.org; Sat, 18 Oct 2003 19:21:35 -0400 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 h9INL5G17938 for ; Sat, 18 Oct 2003 19:21:05 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WQ3K>; Sat, 18 Oct 2003 19:21:05 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8D9@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: Sat, 18 Oct 2003 19:21:04 -0400 Hi Ok. I don't understand your issue. There is no maximum because alarms MUST stay in the table while they are active. There is no wrapping because one of the indices is DataAndTime so therefore always increasing (unless I'm missing something). Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Saturday, October 11, 2003 12:03 AM To: Disman (E-mail) Subject: Re: [Disman] "table wrapping" in alarm MIB -15- Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Friday, October 10, 2003 11:18 AM > Subject: RE: [Disman] "table wrapping" in alarm MIB -15- ... > The following is the proposed resolution to Randy-74-4. Assuming no > objection, this item will is closed with no changes to the draft. > > In the definition of alarmActiveEntry is > " > "Entries appear in this table when alarms are raised. They > are removed when the alarm is cleared." > > One of the indices into this table is DataAndTime object. This table > therefore will not wrap, so discussing what happens when the table > wraps does not make sense. The statement that indicates that entries > are removed when the alarm is cleared implies that entries stay in the > table while they are active. End of story. ... Sorry, it's not. Please re-read my original comment: > > 75-4) I missed anything like an "alarmActiveMaximum", yet the > > document doesn't seem to describe what should happen if there are > > too many active alarms, as might happen if there are lots of > > instances of a particular type of resource, and an administrator > > inadvertently specifies a frequent, innocuous event as being of > > interest. ... The issue still stands. Randy From disman-admin@ietf.org Sat Oct 18 19:27: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 TAA13547 for ; Sat, 18 Oct 2003 19:27:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0TN-000235-Ak; Sat, 18 Oct 2003 19:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0T8-000216-Qf for disman@optimus.ietf.org; Sat, 18 Oct 2003 19:26:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13540 for ; Sat, 18 Oct 2003 19:26:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AB0T7-0000D9-00 for disman@ietf.org; Sat, 18 Oct 2003 19:26:45 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AB0T6-0000Ct-00 for disman@ietf.org; Sat, 18 Oct 2003 19:26:44 -0400 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 h9INQDG18015 for ; Sat, 18 Oct 2003 19:26:14 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WQ3Y>; Sat, 18 Oct 2003 19:26:14 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8DA@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] ituAlarmActiveTrendIndication in draft-ietf-disman-a larm-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: Sat, 18 Oct 2003 19:26:13 -0400 Hi The following is the proposed resolution to Randy-N+2 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. The superfluous space at the beginning of the descriptions of ituAlarmActiveTrendIndication. Ditto alarmActiveStatsGroup, alarmClearGroup, and ituAlarmTc will all be removed. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 02, 2003 6:50 PM To: Disman (E-mail) Subject: [Disman] ituAlarmActiveTrendIndication in draft-ietf-disman-alarm-mib-15.txt Hi - There's a superflous " " at the beginning of the text of the description clause for ituAlarmActiveTrendIndication. Ditto alarmActiveStatsGroup, alarmClearGroup, and ituAlarmTc. Randy From exim@www1.ietf.org Sat Oct 18 19:27:22 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 TAA13562 for ; Sat, 18 Oct 2003 19:27:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0TO-00026Y-Qz for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 19:27:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9INR2bl008084 for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 19:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0TO-00026J-Hy for disman-web-archive@optimus.ietf.org; Sat, 18 Oct 2003 19:27:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13544 for ; Sat, 18 Oct 2003 19:26:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AB0TM-0000DF-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 19:27:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AB0TM-0000DC-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 19:27:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0TN-000235-Ak; Sat, 18 Oct 2003 19:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0T8-000216-Qf for disman@optimus.ietf.org; Sat, 18 Oct 2003 19:26:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13540 for ; Sat, 18 Oct 2003 19:26:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AB0T7-0000D9-00 for disman@ietf.org; Sat, 18 Oct 2003 19:26:45 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AB0T6-0000Ct-00 for disman@ietf.org; Sat, 18 Oct 2003 19:26:44 -0400 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 h9INQDG18015 for ; Sat, 18 Oct 2003 19:26:14 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WQ3Y>; Sat, 18 Oct 2003 19:26:14 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8DA@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] ituAlarmActiveTrendIndication in draft-ietf-disman-a larm-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: Sat, 18 Oct 2003 19:26:13 -0400 Hi The following is the proposed resolution to Randy-N+2 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. The superfluous space at the beginning of the descriptions of ituAlarmActiveTrendIndication. Ditto alarmActiveStatsGroup, alarmClearGroup, and ituAlarmTc will all be removed. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 02, 2003 6:50 PM To: Disman (E-mail) Subject: [Disman] ituAlarmActiveTrendIndication in draft-ietf-disman-alarm-mib-15.txt Hi - There's a superflous " " at the beginning of the text of the description clause for ituAlarmActiveTrendIndication. Ditto alarmActiveStatsGroup, alarmClearGroup, and ituAlarmTc. Randy From disman-admin@ietf.org Sat Oct 18 19:37: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 TAA13721 for ; Sat, 18 Oct 2003 19:37:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0d2-00056K-UJ; Sat, 18 Oct 2003 19:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0cz-00053n-5m for disman@optimus.ietf.org; Sat, 18 Oct 2003 19:36:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13704 for ; Sat, 18 Oct 2003 19:36:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AB0cx-0000GP-00 for disman@ietf.org; Sat, 18 Oct 2003 19:36:55 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AB0cw-0000GC-00 for disman@ietf.org; Sat, 18 Oct 2003 19:36:54 -0400 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 h9INaNG18191 for ; Sat, 18 Oct 2003 19:36:24 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WQQB>; Sat, 18 Oct 2003 19:36:24 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8DD@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Re: alarm MIB question... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: Sat, 18 Oct 2003 19:36:24 -0400 Content-Transfer-Encoding: quoted-printable Hi The following is the proposed resolution to Randy-N+3 Assuming no objection, this item will be considered closed conditional on the = proposed edit being done. In the description of alarmActiveVariableOpaqueVal replace "The value when alarmActiveVariableType is 'opaque'." With "The value when alarmActiveVariableType is 'opaque'. Note that although RFC2578 [RFC2578] forbids the use=20 of Opaque in 'standard' MIB modules, this particular=20 usage is driven by the need to be able to accurately=20 represent any well-formed notification, and justified=20 by the need for backward compatibility." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Tuesday, October 14, 2003 12:22 PM To: Disman (E-mail) Cc: David.Partain@ericsson.com Subject: [Disman] Re: alarm MIB question... Hi - > From: "David Partain (LM/EAB)" > To: ; > Cc: > Sent: Tuesday, October 14, 2003 4:10 AM > Subject: alarm MIB question... > > Hi, > > Can you remind me of the reasoning behind including=20 > alarmActiveVariableOpaqueVal with a syntax of Opaque? Its inclusion=20 > violates RFC 2578: on page 24, section 7.1.9, it states: "The Opaque=20 > type is provided solely for backward-compatibility, and shall not be=20 > used for newly-defined object types." Seems pretty clear to me. =20 > Perhaps you're doing so in the name of backward-compatibility? Or are = > you just choosing to ignore this for the possibility there are=20 > enterprise MIBs that use Opaque for varbinds they sends in a=20 > notification? > > I think the document should clearly state that it violates the=20 > Standard but "we know and here's why". > > Cheers, > > David > > --=20 > Wireless Access Networks E-mail: David.Partain@ericsson.com > Ericsson Research Tel: +46 13 28 41 44 > P.O. Box 1248 Fax: +46 13 28 75 67 > SE-581 12 Link=F6ping, Sweden http://linlab.ericsson.se/ietf You're quite right, and we went through the same discussion during the = IESG review of the Log MIB. Consequently, I agree that a note to the effect = of "we know and here's why" would save us some grief. I suggest the = following words be added to the end of the DESCRIPTION text for alarmActiveVariableOpaqueVal: Note: although the SMI [RFC2578] forbids the use of Opaque in = 'standard' MIB modules, this particular usage is driven by the need to be able to accurately represent any well-formed notification, and justified by the = need for backward compatibility. Randy From exim@www1.ietf.org Sat Oct 18 19:37:24 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 TAA13736 for ; Sat, 18 Oct 2003 19:37:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0d6-00059x-3f for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 19:37:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9INb3Cr019820 for disman-archive@odin.ietf.org; Sat, 18 Oct 2003 19:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0d5-00058s-6E for disman-web-archive@optimus.ietf.org; Sat, 18 Oct 2003 19:37:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13711 for ; Sat, 18 Oct 2003 19:36:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AB0d3-0000Gc-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 19:37:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AB0d2-0000GZ-00 for disman-web-archive@ietf.org; Sat, 18 Oct 2003 19:37:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0d2-00056K-UJ; Sat, 18 Oct 2003 19:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB0cz-00053n-5m for disman@optimus.ietf.org; Sat, 18 Oct 2003 19:36:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13704 for ; Sat, 18 Oct 2003 19:36:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AB0cx-0000GP-00 for disman@ietf.org; Sat, 18 Oct 2003 19:36:55 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AB0cw-0000GC-00 for disman@ietf.org; Sat, 18 Oct 2003 19:36:54 -0400 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 h9INaNG18191 for ; Sat, 18 Oct 2003 19:36:24 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66WQQB>; Sat, 18 Oct 2003 19:36:24 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A8DD@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] Re: alarm MIB question... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: Sat, 18 Oct 2003 19:36:24 -0400 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi The following is the proposed resolution to Randy-N+3 Assuming no objection, this item will be considered closed conditional on the = proposed edit being done. In the description of alarmActiveVariableOpaqueVal replace "The value when alarmActiveVariableType is 'opaque'." With "The value when alarmActiveVariableType is 'opaque'. Note that although RFC2578 [RFC2578] forbids the use=20 of Opaque in 'standard' MIB modules, this particular=20 usage is driven by the need to be able to accurately=20 represent any well-formed notification, and justified=20 by the need for backward compatibility." Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Tuesday, October 14, 2003 12:22 PM To: Disman (E-mail) Cc: David.Partain@ericsson.com Subject: [Disman] Re: alarm MIB question... Hi - > From: "David Partain (LM/EAB)" > To: ; > Cc: > Sent: Tuesday, October 14, 2003 4:10 AM > Subject: alarm MIB question... > > Hi, > > Can you remind me of the reasoning behind including=20 > alarmActiveVariableOpaqueVal with a syntax of Opaque? Its inclusion=20 > violates RFC 2578: on page 24, section 7.1.9, it states: "The Opaque=20 > type is provided solely for backward-compatibility, and shall not be=20 > used for newly-defined object types." Seems pretty clear to me. =20 > Perhaps you're doing so in the name of backward-compatibility? Or are = > you just choosing to ignore this for the possibility there are=20 > enterprise MIBs that use Opaque for varbinds they sends in a=20 > notification? > > I think the document should clearly state that it violates the=20 > Standard but "we know and here's why". > > Cheers, > > David > > --=20 > Wireless Access Networks E-mail: David.Partain@ericsson.com > Ericsson Research Tel: +46 13 28 41 44 > P.O. Box 1248 Fax: +46 13 28 75 67 > SE-581 12 Link=F6ping, Sweden http://linlab.ericsson.se/ietf You're quite right, and we went through the same discussion during the = IESG review of the Log MIB. Consequently, I agree that a note to the effect = of "we know and here's why" would save us some grief. I suggest the = following words be added to the end of the DESCRIPTION text for alarmActiveVariableOpaqueVal: Note: although the SMI [RFC2578] forbids the use of Opaque in = 'standard' MIB modules, this particular usage is driven by the need to be able to accurately represent any well-formed notification, and justified by the = need for backward compatibility. Randy From disman-admin@ietf.org Sun Oct 19 14: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 OAA14539 for ; Sun, 19 Oct 2003 14:34:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABINN-0002nz-IB; Sun, 19 Oct 2003 14:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIMV-0002Nl-IH for disman@optimus.ietf.org; Sun, 19 Oct 2003 14:33:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14498 for ; Sun, 19 Oct 2003 14:32:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABIMS-0007He-00 for disman@ietf.org; Sun, 19 Oct 2003 14:33:04 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ABIMS-0007HT-00 for disman@ietf.org; Sun, 19 Oct 2003 14:33:04 -0400 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 h9JIWXh12977 for ; Sun, 19 Oct 2003 14:32:33 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66W42F>; Sun, 19 Oct 2003 14:32:34 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A932@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, 19 Oct 2003 14:32:32 -0400 Hi Because you can't assume that IP and resourceId is sufficient to identify the source of an alarm when you support multiple context can you? Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 17, 2003 2:17 PM To: Disman (E-mail) Subject: Re: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Friday, October 17, 2003 4:53 AM > 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." ... Why would they (want/need) to create separate alarm lists in order to specify alarms from sources in different SNMP contexts? I'm glad the IP business is resolved, but I return to my original question: > > 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 Oct 19 14:34:29 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 OAA14554 for ; Sun, 19 Oct 2003 14:34:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABINS-0002rY-Sv for disman-archive@odin.ietf.org; Sun, 19 Oct 2003 14:34:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9JIY6Hc011003 for disman-archive@odin.ietf.org; Sun, 19 Oct 2003 14:34:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABINS-0002rO-Pz for disman-web-archive@optimus.ietf.org; Sun, 19 Oct 2003 14:34:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14526 for ; Sun, 19 Oct 2003 14:33:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABINQ-0007IF-00 for disman-web-archive@ietf.org; Sun, 19 Oct 2003 14:34:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABINP-0007IC-00 for disman-web-archive@ietf.org; Sun, 19 Oct 2003 14:34:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABINN-0002nz-IB; Sun, 19 Oct 2003 14:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIMV-0002Nl-IH for disman@optimus.ietf.org; Sun, 19 Oct 2003 14:33:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14498 for ; Sun, 19 Oct 2003 14:32:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABIMS-0007He-00 for disman@ietf.org; Sun, 19 Oct 2003 14:33:04 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ABIMS-0007HT-00 for disman@ietf.org; Sun, 19 Oct 2003 14:33:04 -0400 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 h9JIWXh12977 for ; Sun, 19 Oct 2003 14:32:33 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66W42F>; Sun, 19 Oct 2003 14:32:34 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A932@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, 19 Oct 2003 14:32:32 -0400 Hi Because you can't assume that IP and resourceId is sufficient to identify the source of an alarm when you support multiple context can you? Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 17, 2003 2:17 PM To: Disman (E-mail) Subject: Re: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Friday, October 17, 2003 4:53 AM > 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." ... Why would they (want/need) to create separate alarm lists in order to specify alarms from sources in different SNMP contexts? I'm glad the IP business is resolved, but I return to my original question: > > 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 Oct 19 14:42: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 OAA14721 for ; Sun, 19 Oct 2003 14:42:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIV7-00050K-42; Sun, 19 Oct 2003 14:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIUs-0004y7-Co for disman@optimus.ietf.org; Sun, 19 Oct 2003 14:41:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14711 for ; Sun, 19 Oct 2003 14:41:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABIUp-0007Kp-00 for disman@ietf.org; Sun, 19 Oct 2003 14:41:43 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ABIUp-0007Ki-00 for disman@ietf.org; Sun, 19 Oct 2003 14:41:43 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9JIfC508871 for ; Sun, 19 Oct 2003 14:41:12 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66W4JN>; Sun, 19 Oct 2003 14:41:11 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A936@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] section 3.3.3 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, 19 Oct 2003 14:41:10 -0400 The following is the proposed resolution to Randy-24 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 3.3.3, replace "The Alarm MIB provides a means to tell what Notifications are just informational events or not of interest to the manager for other reasons by not including them in any alarm models. In addition," With "The Alarm MIB provides a means to determine whether a given notification is of interest to managers for purposes of alarm management by permitting inspection of the alarm models. If no entries in the alarmModelTable could match a particular notification, then that notification is not relevant to the alarm models defined. In addition," Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 17, 2003 2:48 PM To: Disman (E-mail) Subject: Re: [Disman] section 3.3.3 in draft-ietf-disman-alarm-mib-15.txt Hi - > From: "Tom Petch" > To: "Sharon Chisholm" ; "Disman (E-mail)" > > Sent: Friday, October 17, 2003 11:21 AM > Subject: Re: [Disman] section 3.3.3 in draft-ietf-disman-alarm-mib-15.txt > > I now find this harder to comprehend and no longer know whether I > agree with it or not:-( > > Is it saying > > "The Alarm MIB allows a manager to specify which Notifications are of > interest for the purposes of alarm management (by having entries for > those Notifications in the alarmModelTable). If no entries in the > alarmModelTable match a particular Notification, then that > Notification plays no part in the defined alarm models. In > addition,..." > > If so, I propose a text along these lines, stressing the positive > aspects not the negative. ... That's fine with me. Randy From exim@www1.ietf.org Sun Oct 19 14:42:22 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 OAA14738 for ; Sun, 19 Oct 2003 14:42:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIV8-00051F-D4 for disman-archive@odin.ietf.org; Sun, 19 Oct 2003 14:42:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9JIg2QO019287 for disman-archive@odin.ietf.org; Sun, 19 Oct 2003 14:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIV8-000510-8C for disman-web-archive@optimus.ietf.org; Sun, 19 Oct 2003 14:42:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14718 for ; Sun, 19 Oct 2003 14:41:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABIV5-0007L1-00 for disman-web-archive@ietf.org; Sun, 19 Oct 2003 14:41:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABIV4-0007Ky-00 for disman-web-archive@ietf.org; Sun, 19 Oct 2003 14:41:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIV7-00050K-42; Sun, 19 Oct 2003 14:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIUs-0004y7-Co for disman@optimus.ietf.org; Sun, 19 Oct 2003 14:41:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14711 for ; Sun, 19 Oct 2003 14:41:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABIUp-0007Kp-00 for disman@ietf.org; Sun, 19 Oct 2003 14:41:43 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ABIUp-0007Ki-00 for disman@ietf.org; Sun, 19 Oct 2003 14:41:43 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9JIfC508871 for ; Sun, 19 Oct 2003 14:41:12 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66W4JN>; Sun, 19 Oct 2003 14:41:11 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A936@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "Disman (E-mail)" Subject: RE: [Disman] section 3.3.3 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, 19 Oct 2003 14:41:10 -0400 The following is the proposed resolution to Randy-24 Assuming no objection, this item will be considered closed conditional on the proposed edit being done. In section 3.3.3, replace "The Alarm MIB provides a means to tell what Notifications are just informational events or not of interest to the manager for other reasons by not including them in any alarm models. In addition," With "The Alarm MIB provides a means to determine whether a given notification is of interest to managers for purposes of alarm management by permitting inspection of the alarm models. If no entries in the alarmModelTable could match a particular notification, then that notification is not relevant to the alarm models defined. In addition," Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Friday, October 17, 2003 2:48 PM To: Disman (E-mail) Subject: Re: [Disman] section 3.3.3 in draft-ietf-disman-alarm-mib-15.txt Hi - > From: "Tom Petch" > To: "Sharon Chisholm" ; "Disman (E-mail)" > > Sent: Friday, October 17, 2003 11:21 AM > Subject: Re: [Disman] section 3.3.3 in draft-ietf-disman-alarm-mib-15.txt > > I now find this harder to comprehend and no longer know whether I > agree with it or not:-( > > Is it saying > > "The Alarm MIB allows a manager to specify which Notifications are of > interest for the purposes of alarm management (by having entries for > those Notifications in the alarmModelTable). If no entries in the > alarmModelTable match a particular Notification, then that > Notification plays no part in the defined alarm models. In > addition,..." > > If so, I propose a text along these lines, stressing the positive > aspects not the negative. ... That's fine with me. Randy From disman-admin@ietf.org Sun Oct 19 15:09: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 PAA15673 for ; Sun, 19 Oct 2003 15:09:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIvE-0003zi-P5; Sun, 19 Oct 2003 15:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIuT-0003ct-HM for disman@optimus.ietf.org; Sun, 19 Oct 2003 15:08:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15516 for ; Sun, 19 Oct 2003 15:08:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABIuQ-0007S3-00 for disman@ietf.org; Sun, 19 Oct 2003 15:08:10 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ABIuP-0007Rl-00 for disman@ietf.org; Sun, 19 Oct 2003 15:08:10 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9JJ7d510070 for ; Sun, 19 Oct 2003 15:07:39 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66W4NP>; Sun, 19 Oct 2003 15:07:38 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A93B@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, 19 Oct 2003 15:07:36 -0400 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. The following object will be added to the ituAlarmTable ituAlarmRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Control for creating and deleting entries. ituAlarmPerceivedSeverity and ituAlarmGenericModel must be set before this row can go active. Entries may be modified while active. Alarms whose ituAlarmRowStatus is not active will not appear in the ituAlarmActiveTable. Setting this object to notInService cannot be used as an alarm suppression mechanism. Entries that are notInService will disappear as described in RFC2579. This row can not be modified or deleted while there is an instance of this alarm in the ituAlarmActiveTable. In these cases, an error of `inconsistentValue' will be returned to the manager." ::= { ituAlarmEntry 6 } And default values of 'other' will be added to ituAlarmEventType and ituAlarmProbableCause and of "" to ituAlarmAdditionalText. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 07, 2003 3:19 PM To: Disman (E-mail) Subject: [Disman] alarm comment 69-1 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 ... > 69-1) ituAlarmEntry: the DESCRIPTION needs to say something about how > rows in this table come into existence. Currently, it looks like > immaculate conception. If these things are created under management > control, then I'd strongly suggest DEFVALs for > ituAlarmPerceivedSeverity, > ituAlarmEventType, ituAlarmProbableCause, and > ituAlarmAdditionalText. ... Let me step through my reasoning for wanting a clearer description of the lifecycle of these things. Perhaps someone can point out where I've gone wrong, or, if my reasoning is correct, how we might fix things. Currently, the table definition reads: ituAlarmTable OBJECT-TYPE SYNTAX SEQUENCE OF ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of ITU Alarm information for possible alarms on the system." ::= { ituAlarmModel 1 } 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 } The DESCRIPTIONs (and lack of RowStatus) would lead one to believe that these are static tables that describe the possible severity levels that can occur on a system. However, the INDEX structure ties these to the alarmModelTable. Entries in the alarmModelTable may be created (and deleted) using AlarmModelRowStatus, so the values of alarmListName and alarmModelIndex may be coming from a manager somewhere. This begs several questions: 1) when a new alarm model is created using RowStatus, do corresponding entries automagically appear in the ituAlarmTable? Do they appear as a side-effect of setting alarmModelSpecificPointer? If so, are the indexing constraints on possible legal values for this pointer enforced by the agent? 2) If corresponding entries automatically appear in the ituAlarmTable when new alarmModelTable entries are created, how are the values for the various columns supplied? 3) if an alarmModelEntry is deleted, what happens to the corresponding ituAlarmModelEntries (since it's a one-to-many relationship due to ituAlarmPerceivedSeverity, I assume they will always appear and disappear six at a time.) Does this help to explain why I'd like the DESCRIPTIONs to better explain what's going on with this table? Randy From exim@www1.ietf.org Sun Oct 19 15:09:22 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 PAA15688 for ; Sun, 19 Oct 2003 15:09:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIvG-00041W-SM for disman-archive@odin.ietf.org; Sun, 19 Oct 2003 15:09:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9JJ92wC015460 for disman-archive@odin.ietf.org; Sun, 19 Oct 2003 15:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIvG-00040q-OV for disman-web-archive@optimus.ietf.org; Sun, 19 Oct 2003 15:09:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15632 for ; Sun, 19 Oct 2003 15:08:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABIvD-0007SJ-00 for disman-web-archive@ietf.org; Sun, 19 Oct 2003 15:08:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABIvD-0007SG-00 for disman-web-archive@ietf.org; Sun, 19 Oct 2003 15:08:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIvE-0003zi-P5; Sun, 19 Oct 2003 15:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIuT-0003ct-HM for disman@optimus.ietf.org; Sun, 19 Oct 2003 15:08:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15516 for ; Sun, 19 Oct 2003 15:08:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABIuQ-0007S3-00 for disman@ietf.org; Sun, 19 Oct 2003 15:08:10 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ABIuP-0007Rl-00 for disman@ietf.org; Sun, 19 Oct 2003 15:08:10 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9JJ7d510070 for ; Sun, 19 Oct 2003 15:07:39 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66W4NP>; Sun, 19 Oct 2003 15:07:38 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A93B@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, 19 Oct 2003 15:07:36 -0400 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. The following object will be added to the ituAlarmTable ituAlarmRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Control for creating and deleting entries. ituAlarmPerceivedSeverity and ituAlarmGenericModel must be set before this row can go active. Entries may be modified while active. Alarms whose ituAlarmRowStatus is not active will not appear in the ituAlarmActiveTable. Setting this object to notInService cannot be used as an alarm suppression mechanism. Entries that are notInService will disappear as described in RFC2579. This row can not be modified or deleted while there is an instance of this alarm in the ituAlarmActiveTable. In these cases, an error of `inconsistentValue' will be returned to the manager." ::= { ituAlarmEntry 6 } And default values of 'other' will be added to ituAlarmEventType and ituAlarmProbableCause and of "" to ituAlarmAdditionalText. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 07, 2003 3:19 PM To: Disman (E-mail) Subject: [Disman] alarm comment 69-1 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 ... > 69-1) ituAlarmEntry: the DESCRIPTION needs to say something about how > rows in this table come into existence. Currently, it looks like > immaculate conception. If these things are created under management > control, then I'd strongly suggest DEFVALs for > ituAlarmPerceivedSeverity, > ituAlarmEventType, ituAlarmProbableCause, and > ituAlarmAdditionalText. ... Let me step through my reasoning for wanting a clearer description of the lifecycle of these things. Perhaps someone can point out where I've gone wrong, or, if my reasoning is correct, how we might fix things. Currently, the table definition reads: ituAlarmTable OBJECT-TYPE SYNTAX SEQUENCE OF ItuAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of ITU Alarm information for possible alarms on the system." ::= { ituAlarmModel 1 } 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 } The DESCRIPTIONs (and lack of RowStatus) would lead one to believe that these are static tables that describe the possible severity levels that can occur on a system. However, the INDEX structure ties these to the alarmModelTable. Entries in the alarmModelTable may be created (and deleted) using AlarmModelRowStatus, so the values of alarmListName and alarmModelIndex may be coming from a manager somewhere. This begs several questions: 1) when a new alarm model is created using RowStatus, do corresponding entries automagically appear in the ituAlarmTable? Do they appear as a side-effect of setting alarmModelSpecificPointer? If so, are the indexing constraints on possible legal values for this pointer enforced by the agent? 2) If corresponding entries automatically appear in the ituAlarmTable when new alarmModelTable entries are created, how are the values for the various columns supplied? 3) if an alarmModelEntry is deleted, what happens to the corresponding ituAlarmModelEntries (since it's a one-to-many relationship due to ituAlarmPerceivedSeverity, I assume they will always appear and disappear six at a time.) Does this help to explain why I'd like the DESCRIPTIONs to better explain what's going on with this table? Randy From disman-admin@ietf.org Sun Oct 19 15:10: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 PAA15812 for ; Sun, 19 Oct 2003 15:10:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIwD-0004Ck-Gf; Sun, 19 Oct 2003 15:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIvq-00047B-Kv for disman@optimus.ietf.org; Sun, 19 Oct 2003 15:09:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15706 for ; Sun, 19 Oct 2003 15:09:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABIvn-0007SQ-00 for disman@ietf.org; Sun, 19 Oct 2003 15:09:35 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ABIvn-0007SM-00 for disman@ietf.org; Sun, 19 Oct 2003 15:09:35 -0400 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 h9JJ94h14106 for ; Sun, 19 Oct 2003 15:09:04 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66W4NX>; Sun, 19 Oct 2003 15:09:03 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A93D@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, 19 Oct 2003 15:09:02 -0400 Hi The following is the proposed resolution to Randy-68. Assuming no objection, this item will is closed with no changes to the draft. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 16, 2003 12:18 PM To: Disman (E-mail) Subject: Re: [Disman] ituAlarmGenericModel is redundant? Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Wednesday, October 15, 2003 10:14 AM > Subject: RE: [Disman] ituAlarmGenericModel is redundant? ... > The following is the proposed resolution to Randy-68. Assuming no > objection, this item will is closed with no changes to the draft. > > ituAlarmGenericModel is useful, not redundant. > > alarmModelTable has > > INDEX { alarmListName, alarmModelIndex, alarmModelState } > > ituAlarmTable has > > INDEX { alarmListName, alarmModelIndex, > ituAlarmPerceivedSeverity } > > Where alarmModelState != ituAlarmPerceivedSeverity > > You may be able to figure out which row in the alarmModelTable this > refers to but maintaining the pointer makes this much faster and > reliable. ... Ah. Thank you. The purpose of this object is to avoid having to scan the alarmModelSpecificPointers for a given model to figure out the mapping. Though I think that's kinda weak, I'm willing to accept the rationale. HOWEVER, Now I *really* want to know how these itu entries come into (and go out of) existence as alarm models come and go. Randy From exim@www1.ietf.org Sun Oct 19 15:10:22 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 PAA15826 for ; Sun, 19 Oct 2003 15:10:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIwE-0004ET-Pj for disman-archive@odin.ietf.org; Sun, 19 Oct 2003 15:10:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9JJA29U016263 for disman-archive@odin.ietf.org; Sun, 19 Oct 2003 15:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIwE-0004EE-MM for disman-web-archive@optimus.ietf.org; Sun, 19 Oct 2003 15:10:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15745 for ; Sun, 19 Oct 2003 15:09:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABIwB-0007Ss-00 for disman-web-archive@ietf.org; Sun, 19 Oct 2003 15:09:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABIwB-0007So-00 for disman-web-archive@ietf.org; Sun, 19 Oct 2003 15:09:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIwD-0004Ck-Gf; Sun, 19 Oct 2003 15:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABIvq-00047B-Kv for disman@optimus.ietf.org; Sun, 19 Oct 2003 15:09:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15706 for ; Sun, 19 Oct 2003 15:09:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABIvn-0007SQ-00 for disman@ietf.org; Sun, 19 Oct 2003 15:09:35 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ABIvn-0007SM-00 for disman@ietf.org; Sun, 19 Oct 2003 15:09:35 -0400 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 h9JJ94h14106 for ; Sun, 19 Oct 2003 15:09:04 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66W4NX>; Sun, 19 Oct 2003 15:09:03 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0A93D@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, 19 Oct 2003 15:09:02 -0400 Hi The following is the proposed resolution to Randy-68. Assuming no objection, this item will is closed with no changes to the draft. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 16, 2003 12:18 PM To: Disman (E-mail) Subject: Re: [Disman] ituAlarmGenericModel is redundant? Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Wednesday, October 15, 2003 10:14 AM > Subject: RE: [Disman] ituAlarmGenericModel is redundant? ... > The following is the proposed resolution to Randy-68. Assuming no > objection, this item will is closed with no changes to the draft. > > ituAlarmGenericModel is useful, not redundant. > > alarmModelTable has > > INDEX { alarmListName, alarmModelIndex, alarmModelState } > > ituAlarmTable has > > INDEX { alarmListName, alarmModelIndex, > ituAlarmPerceivedSeverity } > > Where alarmModelState != ituAlarmPerceivedSeverity > > You may be able to figure out which row in the alarmModelTable this > refers to but maintaining the pointer makes this much faster and > reliable. ... Ah. Thank you. The purpose of this object is to avoid having to scan the alarmModelSpecificPointers for a given model to figure out the mapping. Though I think that's kinda weak, I'm willing to accept the rationale. HOWEVER, Now I *really* want to know how these itu entries come into (and go out of) existence as alarm models come and go. Randy From disman-admin@ietf.org Mon Oct 20 08:40:32 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 IAA23683 for ; Mon, 20 Oct 2003 08:40:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABZKO-0004eI-FZ; Mon, 20 Oct 2003 08:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABZJo-0004Sb-Vo for disman@optimus.ietf.org; Mon, 20 Oct 2003 08:39:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23646 for ; Mon, 20 Oct 2003 08:39:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABZJn-0007Wr-00 for disman@ietf.org; Mon, 20 Oct 2003 08:39:27 -0400 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ABZJn-0007Wo-00 for disman@ietf.org; Mon, 20 Oct 2003 08:39:27 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9KCd0FY020450 for ; Mon, 20 Oct 2003 08:39:00 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9KCcwFY020404 for ; Mon, 20 Oct 2003 08:38:59 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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 Message-ID: Thread-Topic: [Disman] alarm comment 69-1 Thread-Index: AcOWdJHO0Nco6JiwT/+wXUfLSNoc0QAkYHqw 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: Mon, 20 Oct 2003 14:39:23 +0200 Content-Transfer-Encoding: quoted-printable I do not think that this change reflects our intentions with the = ituAlarmTable.=20 For a specific device / system entries in this table are specific to the = device / system capabilities. A manager cannot create new entries, if = there are no capabilities to support the EventType and Probable Cause. = This is why we decided from the beginning that entries are created in = this table 'automagically', when the model is supported, by the agent, = function of the system / device capabilities. What a manager can change = is the perceived severity he/she wants the alarm to be stamped with, and = the additional text.=20 I think that the fix is to make ituAlarmEventType and = ituAlarmProbableCause read-only, but not to add a RowStatus object. Regards, Dan > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > Sent: 19 October, 2003 9:08 PM > To: Disman (E-mail) > Subject: RE: [Disman] alarm comment 69-1 >=20 >=20 > Hi >=20 > The following is the proposed resolution to Randy-69-1 Assuming no > objection, this item will be considered closed conditional on=20 > the proposed > edit being done. >=20 > The following object will be added to the ituAlarmTable >=20 > ituAlarmRowStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Control for creating and deleting entries. =20 > =20 > ituAlarmPerceivedSeverity and ituAlarmGenericModel must=20 > be set before this row can go active. Entries may be > modified while active. Alarms whose ituAlarmRowStatus is > not active will not appear in the ituAlarmActiveTable. > Setting this object to notInService > cannot be used as an alarm suppression mechanism. Entries > that are notInService will disappear as described in RFC2579. >=20 > This row can not be modified or deleted while there is an=20 > instance of this alarm in the ituAlarmActiveTable. In these > cases, an error of `inconsistentValue' will be returned to > the manager." > ::=3D { ituAlarmEntry 6 } >=20 > And default values of 'other' will be added to ituAlarmEventType and > ituAlarmProbableCause and of "" to ituAlarmAdditionalText. >=20 > Sharon >=20 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 > Sent: Tuesday, October 07, 2003 3:19 PM > To: Disman (E-mail) > Subject: [Disman] alarm comment 69-1 >=20 >=20 > Hi - >=20 > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Cc: ; "Randy Presuhn"=20 > > ; "Romascanu, Dan (Dan)" > > > Sent: Monday, September 29, 2003 7:34 AM > > Subject: [Disman] RE: Comments on draft-ietf-disman-alarm-mib-14.txt > ... > > 69-1) ituAlarmEntry: the DESCRIPTION needs to say something=20 > about how > > rows in this table come into existence. Currently, it=20 > looks like > > immaculate conception. If these things are created=20 > under management > > control, then I'd strongly suggest DEFVALs for=20 > > ituAlarmPerceivedSeverity, > > ituAlarmEventType, ituAlarmProbableCause, and=20 > > ituAlarmAdditionalText. > ... >=20 > Let me step through my reasoning for wanting a clearer=20 > description of the > lifecycle of these things. Perhaps someone can point out=20 > where I've gone > wrong, or, if my reasoning is correct, how we might fix things. >=20 > Currently, the table definition reads: > ituAlarmTable OBJECT-TYPE > SYNTAX SEQUENCE OF ItuAlarmEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of ITU Alarm information for possible alarms > on the system." > ::=3D { ituAlarmModel 1 } >=20 > 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 } > ::=3D { ituAlarmTable 1 } >=20 > The DESCRIPTIONs (and lack of RowStatus) would lead one to=20 > believe that > these are static tables that describe the possible severity=20 > levels that can > occur on a system. However, the INDEX structure ties these to the > alarmModelTable. Entries in the alarmModelTable may be=20 > created (and deleted) > using AlarmModelRowStatus, so the values of alarmListName and > alarmModelIndex may be coming from a manager somewhere. This=20 > begs several > questions: > 1) when a new alarm model is created using RowStatus, do=20 > corresponding > entries automagically appear in the ituAlarmTable? =20 > Do they appear > as > a side-effect of setting alarmModelSpecificPointer? =20 > If so, are the > indexing constraints on possible legal values for this pointer > enforced > by the agent? > 2) If corresponding entries automatically appear in the=20 > ituAlarmTable > when > new alarmModelTable entries are created, how are the=20 > values for the > various columns supplied? > 3) if an alarmModelEntry is deleted, what happens to the=20 > corresponding > ituAlarmModelEntries (since it's a one-to-many=20 > relationship due to > ituAlarmPerceivedSeverity, I assume they will always=20 > appear and > disappear > six at a time.) >=20 > Does this help to explain why I'd like the DESCRIPTIONs to=20 > better explain > what's going on with this table? >=20 > Randy >=20 >=20 >=20 >=20 >=20 From exim@www1.ietf.org Mon Oct 20 08:40:40 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 IAA23698 for ; Mon, 20 Oct 2003 08:40:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABZKb-0004hq-OC for disman-archive@odin.ietf.org; Mon, 20 Oct 2003 08:40:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KCeF6k018064 for disman-archive@odin.ietf.org; Mon, 20 Oct 2003 08:40:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABZKX-0004gX-Jr for disman-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 08:40:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23665 for ; Mon, 20 Oct 2003 08:40:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABZKU-0007XC-00 for disman-web-archive@ietf.org; Mon, 20 Oct 2003 08:40:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABZKU-0007X8-00 for disman-web-archive@ietf.org; Mon, 20 Oct 2003 08:40:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABZKO-0004eI-FZ; Mon, 20 Oct 2003 08:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABZJo-0004Sb-Vo for disman@optimus.ietf.org; Mon, 20 Oct 2003 08:39:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23646 for ; Mon, 20 Oct 2003 08:39:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABZJn-0007Wr-00 for disman@ietf.org; Mon, 20 Oct 2003 08:39:27 -0400 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ABZJn-0007Wo-00 for disman@ietf.org; Mon, 20 Oct 2003 08:39:27 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9KCd0FY020450 for ; Mon, 20 Oct 2003 08:39:00 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9KCcwFY020404 for ; Mon, 20 Oct 2003 08:38:59 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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 Message-ID: Thread-Topic: [Disman] alarm comment 69-1 Thread-Index: AcOWdJHO0Nco6JiwT/+wXUfLSNoc0QAkYHqw 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: Mon, 20 Oct 2003 14:39:23 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I do not think that this change reflects our intentions with the = ituAlarmTable.=20 For a specific device / system entries in this table are specific to the = device / system capabilities. A manager cannot create new entries, if = there are no capabilities to support the EventType and Probable Cause. = This is why we decided from the beginning that entries are created in = this table 'automagically', when the model is supported, by the agent, = function of the system / device capabilities. What a manager can change = is the perceived severity he/she wants the alarm to be stamped with, and = the additional text.=20 I think that the fix is to make ituAlarmEventType and = ituAlarmProbableCause read-only, but not to add a RowStatus object. Regards, Dan > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > Sent: 19 October, 2003 9:08 PM > To: Disman (E-mail) > Subject: RE: [Disman] alarm comment 69-1 >=20 >=20 > Hi >=20 > The following is the proposed resolution to Randy-69-1 Assuming no > objection, this item will be considered closed conditional on=20 > the proposed > edit being done. >=20 > The following object will be added to the ituAlarmTable >=20 > ituAlarmRowStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Control for creating and deleting entries. =20 > =20 > ituAlarmPerceivedSeverity and ituAlarmGenericModel must=20 > be set before this row can go active. Entries may be > modified while active. Alarms whose ituAlarmRowStatus is > not active will not appear in the ituAlarmActiveTable. > Setting this object to notInService > cannot be used as an alarm suppression mechanism. Entries > that are notInService will disappear as described in RFC2579. >=20 > This row can not be modified or deleted while there is an=20 > instance of this alarm in the ituAlarmActiveTable. In these > cases, an error of `inconsistentValue' will be returned to > the manager." > ::=3D { ituAlarmEntry 6 } >=20 > And default values of 'other' will be added to ituAlarmEventType and > ituAlarmProbableCause and of "" to ituAlarmAdditionalText. >=20 > Sharon >=20 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 > Sent: Tuesday, October 07, 2003 3:19 PM > To: Disman (E-mail) > Subject: [Disman] alarm comment 69-1 >=20 >=20 > Hi - >=20 > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Cc: ; "Randy Presuhn"=20 > > ; "Romascanu, Dan (Dan)" > > > Sent: Monday, September 29, 2003 7:34 AM > > Subject: [Disman] RE: Comments on draft-ietf-disman-alarm-mib-14.txt > ... > > 69-1) ituAlarmEntry: the DESCRIPTION needs to say something=20 > about how > > rows in this table come into existence. Currently, it=20 > looks like > > immaculate conception. If these things are created=20 > under management > > control, then I'd strongly suggest DEFVALs for=20 > > ituAlarmPerceivedSeverity, > > ituAlarmEventType, ituAlarmProbableCause, and=20 > > ituAlarmAdditionalText. > ... >=20 > Let me step through my reasoning for wanting a clearer=20 > description of the > lifecycle of these things. Perhaps someone can point out=20 > where I've gone > wrong, or, if my reasoning is correct, how we might fix things. >=20 > Currently, the table definition reads: > ituAlarmTable OBJECT-TYPE > SYNTAX SEQUENCE OF ItuAlarmEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of ITU Alarm information for possible alarms > on the system." > ::=3D { ituAlarmModel 1 } >=20 > 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 } > ::=3D { ituAlarmTable 1 } >=20 > The DESCRIPTIONs (and lack of RowStatus) would lead one to=20 > believe that > these are static tables that describe the possible severity=20 > levels that can > occur on a system. However, the INDEX structure ties these to the > alarmModelTable. Entries in the alarmModelTable may be=20 > created (and deleted) > using AlarmModelRowStatus, so the values of alarmListName and > alarmModelIndex may be coming from a manager somewhere. This=20 > begs several > questions: > 1) when a new alarm model is created using RowStatus, do=20 > corresponding > entries automagically appear in the ituAlarmTable? =20 > Do they appear > as > a side-effect of setting alarmModelSpecificPointer? =20 > If so, are the > indexing constraints on possible legal values for this pointer > enforced > by the agent? > 2) If corresponding entries automatically appear in the=20 > ituAlarmTable > when > new alarmModelTable entries are created, how are the=20 > values for the > various columns supplied? > 3) if an alarmModelEntry is deleted, what happens to the=20 > corresponding > ituAlarmModelEntries (since it's a one-to-many=20 > relationship due to > ituAlarmPerceivedSeverity, I assume they will always=20 > appear and > disappear > six at a time.) >=20 > Does this help to explain why I'd like the DESCRIPTIONs to=20 > better explain > what's going on with this table? >=20 > Randy >=20 >=20 >=20 >=20 >=20 From disman-admin@ietf.org Mon Oct 20 09:18: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 JAA25064 for ; Mon, 20 Oct 2003 09:18:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABZv7-0007Fl-S5; Mon, 20 Oct 2003 09:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABZuw-00079k-5X for disman@optimus.ietf.org; Mon, 20 Oct 2003 09:17:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25041 for ; Mon, 20 Oct 2003 09:17:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABZus-000045-00 for disman@ietf.org; Mon, 20 Oct 2003 09:17:46 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ABZus-00003m-00 for disman@ietf.org; Mon, 20 Oct 2003 09:17:46 -0400 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 h9KDHDO21637 for ; Mon, 20 Oct 2003 09:17:13 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66W5X7>; Mon, 20 Oct 2003 09:17:13 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0AB05@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, 20 Oct 2003 09:17:13 -0400 Hi 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. Sharon -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Monday, October 20, 2003 8:39 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; Disman (E-mail) Subject: RE: [Disman] alarm comment 69-1 I do not think that this change reflects our intentions with the ituAlarmTable. For a specific device / system entries in this table are specific to the device / system capabilities. A manager cannot create new entries, if there are no capabilities to support the EventType and Probable Cause. This is why we decided from the beginning that entries are created in this table 'automagically', when the model is supported, by the agent, function of the system / device capabilities. What a manager can change is the perceived severity he/she wants the alarm to be stamped with, and the additional text. I think that the fix is to make ituAlarmEventType and ituAlarmProbableCause read-only, but not to add a RowStatus object. Regards, Dan > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > Sent: 19 October, 2003 9:08 PM > To: Disman (E-mail) > 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. > > The following object will be added to the ituAlarmTable > > ituAlarmRowStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Control for creating and deleting entries. > > ituAlarmPerceivedSeverity and ituAlarmGenericModel must > be set before this row can go active. Entries may be > modified while active. Alarms whose ituAlarmRowStatus is > not active will not appear in the ituAlarmActiveTable. > Setting this object to notInService > cannot be used as an alarm suppression mechanism. Entries > that are notInService will disappear as described in RFC2579. > > This row can not be modified or deleted while there is an > instance of this alarm in the ituAlarmActiveTable. In these > cases, an error of `inconsistentValue' will be returned to > the manager." > ::= { ituAlarmEntry 6 } > > And default values of 'other' will be added to ituAlarmEventType and > ituAlarmProbableCause and of "" to ituAlarmAdditionalText. > > Sharon > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Tuesday, October 07, 2003 3:19 PM > To: Disman (E-mail) > Subject: [Disman] alarm comment 69-1 > > > 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 > ... > > 69-1) ituAlarmEntry: the DESCRIPTION needs to say something > about how > > rows in this table come into existence. Currently, it > looks like > > immaculate conception. If these things are created > under management > > control, then I'd strongly suggest DEFVALs for > > ituAlarmPerceivedSeverity, > > ituAlarmEventType, ituAlarmProbableCause, and > > ituAlarmAdditionalText. > ... > > Let me step through my reasoning for wanting a clearer > description of the > lifecycle of these things. Perhaps someone can point out > where I've gone > wrong, or, if my reasoning is correct, how we might fix things. > > Currently, the table definition reads: > ituAlarmTable OBJECT-TYPE > SYNTAX SEQUENCE OF ItuAlarmEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of ITU Alarm information for possible alarms > on the system." > ::= { ituAlarmModel 1 } > > 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 } > > The DESCRIPTIONs (and lack of RowStatus) would lead one to > believe that > these are static tables that describe the possible severity > levels that can > occur on a system. However, the INDEX structure ties these to the > alarmModelTable. Entries in the alarmModelTable may be > created (and deleted) > using AlarmModelRowStatus, so the values of alarmListName and > alarmModelIndex may be coming from a manager somewhere. This > begs several > questions: > 1) when a new alarm model is created using RowStatus, do > corresponding > entries automagically appear in the ituAlarmTable? > Do they appear > as > a side-effect of setting alarmModelSpecificPointer? > If so, are the > indexing constraints on possible legal values for this pointer > enforced > by the agent? > 2) If corresponding entries automatically appear in the > ituAlarmTable > when > new alarmModelTable entries are created, how are the > values for the > various columns supplied? > 3) if an alarmModelEntry is deleted, what happens to the > corresponding > ituAlarmModelEntries (since it's a one-to-many > relationship due to > ituAlarmPerceivedSeverity, I assume they will always > appear and > disappear > six at a time.) > > Does this help to explain why I'd like the DESCRIPTIONs to > better explain > what's going on with this table? > > Randy > > > > > From exim@www1.ietf.org Mon Oct 20 09:18:24 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 JAA25076 for ; Mon, 20 Oct 2003 09:18:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABZv9-0007Gy-7u for disman-archive@odin.ietf.org; Mon, 20 Oct 2003 09:18:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KDI3ZS027955 for disman-archive@odin.ietf.org; Mon, 20 Oct 2003 09:18:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABZv9-0007Go-30 for disman-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 09:18:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25046 for ; Mon, 20 Oct 2003 09:17:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABZv7-00004L-00 for disman-web-archive@ietf.org; Mon, 20 Oct 2003 09:18:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABZv6-00004I-00 for disman-web-archive@ietf.org; Mon, 20 Oct 2003 09:18:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABZv7-0007Fl-S5; Mon, 20 Oct 2003 09:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABZuw-00079k-5X for disman@optimus.ietf.org; Mon, 20 Oct 2003 09:17:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25041 for ; Mon, 20 Oct 2003 09:17:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABZus-000045-00 for disman@ietf.org; Mon, 20 Oct 2003 09:17:46 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ABZus-00003m-00 for disman@ietf.org; Mon, 20 Oct 2003 09:17:46 -0400 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 h9KDHDO21637 for ; Mon, 20 Oct 2003 09:17:13 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4S66W5X7>; Mon, 20 Oct 2003 09:17:13 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F0AB05@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, 20 Oct 2003 09:17:13 -0400 Hi 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. Sharon -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Monday, October 20, 2003 8:39 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; Disman (E-mail) Subject: RE: [Disman] alarm comment 69-1 I do not think that this change reflects our intentions with the ituAlarmTable. For a specific device / system entries in this table are specific to the device / system capabilities. A manager cannot create new entries, if there are no capabilities to support the EventType and Probable Cause. This is why we decided from the beginning that entries are created in this table 'automagically', when the model is supported, by the agent, function of the system / device capabilities. What a manager can change is the perceived severity he/she wants the alarm to be stamped with, and the additional text. I think that the fix is to make ituAlarmEventType and ituAlarmProbableCause read-only, but not to add a RowStatus object. Regards, Dan > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > Sent: 19 October, 2003 9:08 PM > To: Disman (E-mail) > 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. > > The following object will be added to the ituAlarmTable > > ituAlarmRowStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Control for creating and deleting entries. > > ituAlarmPerceivedSeverity and ituAlarmGenericModel must > be set before this row can go active. Entries may be > modified while active. Alarms whose ituAlarmRowStatus is > not active will not appear in the ituAlarmActiveTable. > Setting this object to notInService > cannot be used as an alarm suppression mechanism. Entries > that are notInService will disappear as described in RFC2579. > > This row can not be modified or deleted while there is an > instance of this alarm in the ituAlarmActiveTable. In these > cases, an error of `inconsistentValue' will be returned to > the manager." > ::= { ituAlarmEntry 6 } > > And default values of 'other' will be added to ituAlarmEventType and > ituAlarmProbableCause and of "" to ituAlarmAdditionalText. > > Sharon > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Tuesday, October 07, 2003 3:19 PM > To: Disman (E-mail) > Subject: [Disman] alarm comment 69-1 > > > 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 > ... > > 69-1) ituAlarmEntry: the DESCRIPTION needs to say something > about how > > rows in this table come into existence. Currently, it > looks like > > immaculate conception. If these things are created > under management > > control, then I'd strongly suggest DEFVALs for > > ituAlarmPerceivedSeverity, > > ituAlarmEventType, ituAlarmProbableCause, and > > ituAlarmAdditionalText. > ... > > Let me step through my reasoning for wanting a clearer > description of the > lifecycle of these things. Perhaps someone can point out > where I've gone > wrong, or, if my reasoning is correct, how we might fix things. > > Currently, the table definition reads: > ituAlarmTable OBJECT-TYPE > SYNTAX SEQUENCE OF ItuAlarmEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of ITU Alarm information for possible alarms > on the system." > ::= { ituAlarmModel 1 } > > 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 } > > The DESCRIPTIONs (and lack of RowStatus) would lead one to > believe that > these are static tables that describe the possible severity > levels that can > occur on a system. However, the INDEX structure ties these to the > alarmModelTable. Entries in the alarmModelTable may be > created (and deleted) > using AlarmModelRowStatus, so the values of alarmListName and > alarmModelIndex may be coming from a manager somewhere. This > begs several > questions: > 1) when a new alarm model is created using RowStatus, do > corresponding > entries automagically appear in the ituAlarmTable? > Do they appear > as > a side-effect of setting alarmModelSpecificPointer? > If so, are the > indexing constraints on possible legal values for this pointer > enforced > by the agent? > 2) If corresponding entries automatically appear in the > ituAlarmTable > when > new alarmModelTable entries are created, how are the > values for the > various columns supplied? > 3) if an alarmModelEntry is deleted, what happens to the > corresponding > ituAlarmModelEntries (since it's a one-to-many > relationship due to > ituAlarmPerceivedSeverity, I assume they will always > appear and > disappear > six at a time.) > > Does this help to explain why I'd like the DESCRIPTIONs to > better explain > what's going on with this table? > > Randy > > > > > From disman-admin@ietf.org Tue Oct 21 19:47: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 TAA19738 for ; Tue, 21 Oct 2003 19:47:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6DN-00052Z-9M; Tue, 21 Oct 2003 19:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6DM-000528-F7 for disman@optimus.ietf.org; Tue, 21 Oct 2003 19:47:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19649 for ; Tue, 21 Oct 2003 19:46:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC6DK-00058n-00 for disman@ietf.org; Tue, 21 Oct 2003 19:46:58 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AC6DI-00057R-00 for disman@ietf.org; Tue, 21 Oct 2003 19:46:58 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 21 Oct 2003 16:47:15 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9LNkOjP026962; Tue, 21 Oct 2003 16:46:25 -0700 (PDT) Received: from cisco.com (dhcp-128-107-166-145.cisco.com [128.107.166.145]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMT12679; Tue, 21 Oct 2003 16:45:31 -0700 (PDT) Message-ID: <3F95C54F.2030305@cisco.com> From: Ramanathan Kavasseri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn CC: "Disman (E-mail)" Subject: Re: [Disman] Fw: training in Minneapolis References: <002301c3942b$bd90e4c0$7f1afea9@oemcomputer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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, 21 Oct 2003 16:46:23 -0700 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > Hi - > > >>From: >>To: ; >>Sent: Thursday, October 16, 2003 2:04 PM > > ... > >>We will also be presenting a new editor's training session in >>Minneapolis, as follows: >> >> Sunday, November 10, 2003 ^^^^^^^^^^^^^^^^^^^^^^^^^ Nov 10th is a Monday, not Sunday. :-| Ram >> ========================= >> 1330-1500 Editor's Training -- Conrad C >> >> Training for current or aspiring IETF document >> editors. Covers the roles and responsibilities >> of a document editor, and includes advice on >> producing a high-quality IETF specification. >> > > ... > > If you currently edit a document or are thinking about becoming > an editor of a WG document, this is RECOMMENDED. > > Randy > > > From exim@www1.ietf.org Tue Oct 21 19:47:28 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 TAA19753 for ; Tue, 21 Oct 2003 19:47:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6DV-00056w-6b for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 19:47:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LNl9kZ019642 for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 19:47:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6DV-00056j-2N for disman-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 19:47:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19687 for ; Tue, 21 Oct 2003 19:46:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC6DS-00059O-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 19:47:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC6DS-00059I-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 19:47:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6DN-00052Z-9M; Tue, 21 Oct 2003 19:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6DM-000528-F7 for disman@optimus.ietf.org; Tue, 21 Oct 2003 19:47:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19649 for ; Tue, 21 Oct 2003 19:46:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC6DK-00058n-00 for disman@ietf.org; Tue, 21 Oct 2003 19:46:58 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AC6DI-00057R-00 for disman@ietf.org; Tue, 21 Oct 2003 19:46:58 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 21 Oct 2003 16:47:15 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9LNkOjP026962; Tue, 21 Oct 2003 16:46:25 -0700 (PDT) Received: from cisco.com (dhcp-128-107-166-145.cisco.com [128.107.166.145]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMT12679; Tue, 21 Oct 2003 16:45:31 -0700 (PDT) Message-ID: <3F95C54F.2030305@cisco.com> From: Ramanathan Kavasseri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn CC: "Disman (E-mail)" Subject: Re: [Disman] Fw: training in Minneapolis References: <002301c3942b$bd90e4c0$7f1afea9@oemcomputer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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, 21 Oct 2003 16:46:23 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > Hi - > > >>From: >>To: ; >>Sent: Thursday, October 16, 2003 2:04 PM > > ... > >>We will also be presenting a new editor's training session in >>Minneapolis, as follows: >> >> Sunday, November 10, 2003 ^^^^^^^^^^^^^^^^^^^^^^^^^ Nov 10th is a Monday, not Sunday. :-| Ram >> ========================= >> 1330-1500 Editor's Training -- Conrad C >> >> Training for current or aspiring IETF document >> editors. Covers the roles and responsibilities >> of a document editor, and includes advice on >> producing a high-quality IETF specification. >> > > ... > > If you currently edit a document or are thinking about becoming > an editor of a WG document, this is RECOMMENDED. > > Randy > > > From disman-admin@ietf.org Tue Oct 21 19:49: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 TAA19931 for ; Tue, 21 Oct 2003 19:49:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6FI-0005Xq-Og; Tue, 21 Oct 2003 19:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6ER-0005KW-Al for disman@optimus.ietf.org; Tue, 21 Oct 2003 19:48:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19798 for ; Tue, 21 Oct 2003 19:47:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC6EP-0005BI-00 for disman@ietf.org; Tue, 21 Oct 2003 19:48:05 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AC6EO-0005AT-00 for disman@ietf.org; Tue, 21 Oct 2003 19:48:05 -0400 Received: from cisco.com (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 22 Oct 2003 01:45:36 +0200 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9LNlViw020733; Tue, 21 Oct 2003 16:47:31 -0700 (PDT) Received: from cisco.com (dhcp-128-107-166-145.cisco.com [128.107.166.145]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMT12796; Tue, 21 Oct 2003 16:46:38 -0700 (PDT) Message-ID: <3F95C592.9000408@cisco.com> From: Ramanathan Kavasseri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn CC: "Disman (E-mail)" Subject: Re: [Disman] Fw: training in Minneapolis References: <002301c3942b$bd90e4c0$7f1afea9@oemcomputer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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, 21 Oct 2003 16:47:30 -0700 Content-Transfer-Encoding: 7bit Nevermind - it's Sunday Nov 10th. Just checked on the Agenda page. Ram Randy Presuhn wrote: > Hi - > > >>From: >>To: ; >>Sent: Thursday, October 16, 2003 2:04 PM > > ... > >>We will also be presenting a new editor's training session in >>Minneapolis, as follows: >> >> Sunday, November 10, 2003 >> ========================= >> 1330-1500 Editor's Training -- Conrad C >> >> Training for current or aspiring IETF document >> editors. Covers the roles and responsibilities >> of a document editor, and includes advice on >> producing a high-quality IETF specification. >> > > ... > > If you currently edit a document or are thinking about becoming > an editor of a WG document, this is RECOMMENDED. > > Randy > > > From exim@www1.ietf.org Tue Oct 21 19:49: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 TAA19946 for ; Tue, 21 Oct 2003 19:49:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6FJ-0005ZU-Ti for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 19:49:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LNn1Aj021410 for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 19:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6FJ-0005ZF-PT for disman-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 19:49:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19905 for ; Tue, 21 Oct 2003 19:48:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC6FH-0005Cz-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 19:48:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC6FH-0005Cw-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 19:48:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6FI-0005Xq-Og; Tue, 21 Oct 2003 19:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6ER-0005KW-Al for disman@optimus.ietf.org; Tue, 21 Oct 2003 19:48:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19798 for ; Tue, 21 Oct 2003 19:47:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC6EP-0005BI-00 for disman@ietf.org; Tue, 21 Oct 2003 19:48:05 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AC6EO-0005AT-00 for disman@ietf.org; Tue, 21 Oct 2003 19:48:05 -0400 Received: from cisco.com (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 22 Oct 2003 01:45:36 +0200 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9LNlViw020733; Tue, 21 Oct 2003 16:47:31 -0700 (PDT) Received: from cisco.com (dhcp-128-107-166-145.cisco.com [128.107.166.145]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMT12796; Tue, 21 Oct 2003 16:46:38 -0700 (PDT) Message-ID: <3F95C592.9000408@cisco.com> From: Ramanathan Kavasseri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn CC: "Disman (E-mail)" Subject: Re: [Disman] Fw: training in Minneapolis References: <002301c3942b$bd90e4c0$7f1afea9@oemcomputer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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, 21 Oct 2003 16:47:30 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Nevermind - it's Sunday Nov 10th. Just checked on the Agenda page. Ram Randy Presuhn wrote: > Hi - > > >>From: >>To: ; >>Sent: Thursday, October 16, 2003 2:04 PM > > ... > >>We will also be presenting a new editor's training session in >>Minneapolis, as follows: >> >> Sunday, November 10, 2003 >> ========================= >> 1330-1500 Editor's Training -- Conrad C >> >> Training for current or aspiring IETF document >> editors. Covers the roles and responsibilities >> of a document editor, and includes advice on >> producing a high-quality IETF specification. >> > > ... > > If you currently edit a document or are thinking about becoming > an editor of a WG document, this is RECOMMENDED. > > Randy > > > From disman-admin@ietf.org Tue Oct 21 19:54: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 TAA20240 for ; Tue, 21 Oct 2003 19:54:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6K8-0006hH-GQ; Tue, 21 Oct 2003 19:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6K3-0006eT-7s for disman@optimus.ietf.org; Tue, 21 Oct 2003 19:53:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20188 for ; Tue, 21 Oct 2003 19:53:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC6K1-0005J5-00 for disman@ietf.org; Tue, 21 Oct 2003 19:53:53 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AC6K0-0005Iw-00 for disman@ietf.org; Tue, 21 Oct 2003 19:53:52 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AC6Jw-0000LX-00 for disman@ietf.org; Tue, 21 Oct 2003 16:53:48 -0700 Message-ID: <009501c3982e$aba76de0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <002301c3942b$bd90e4c0$7f1afea9@oemcomputer> <3F95C54F.2030305@cisco.com> Subject: Re: [Disman] Fw: training in Minneapolis 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: Tue, 21 Oct 2003 16:54:30 -0700 Hi - > From: "Ramanathan Kavasseri" > To: "Randy Presuhn" > Cc: "Disman (E-mail)" > Sent: Tuesday, October 21, 2003 4:46 PM > Subject: Re: [Disman] Fw: training in Minneapolis ... > >>From: > >>To: ; > >>Sent: Thursday, October 16, 2003 2:04 PM > > > > ... > > > >>We will also be presenting a new editor's training session in > >>Minneapolis, as follows: > >> > >> Sunday, November 10, 2003 > ^^^^^^^^^^^^^^^^^^^^^^^^^ > Nov 10th is a Monday, not Sunday. > :-| > > Ram > > >> ========================= > >> 1330-1500 Editor's Training -- Conrad C ... True, but the session is indeed on Sunday, and is still RECOMMENDED. For more information, see http://www.ietf.org/meetings/agenda_58.html Randy From exim@www1.ietf.org Tue Oct 21 19:54: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 TAA20255 for ; Tue, 21 Oct 2003 19:54:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6K9-0006ie-OF for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 19:54:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LNs1K9025822 for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 19:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6K9-0006iP-I5 for disman-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 19:54:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20203 for ; Tue, 21 Oct 2003 19:53:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC6K7-0005JR-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 19:53:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC6K7-0005JO-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 19:53:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6K8-0006hH-GQ; Tue, 21 Oct 2003 19:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6K3-0006eT-7s for disman@optimus.ietf.org; Tue, 21 Oct 2003 19:53:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20188 for ; Tue, 21 Oct 2003 19:53:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC6K1-0005J5-00 for disman@ietf.org; Tue, 21 Oct 2003 19:53:53 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AC6K0-0005Iw-00 for disman@ietf.org; Tue, 21 Oct 2003 19:53:52 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AC6Jw-0000LX-00 for disman@ietf.org; Tue, 21 Oct 2003 16:53:48 -0700 Message-ID: <009501c3982e$aba76de0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <002301c3942b$bd90e4c0$7f1afea9@oemcomputer> <3F95C54F.2030305@cisco.com> Subject: Re: [Disman] Fw: training in Minneapolis 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: Tue, 21 Oct 2003 16:54:30 -0700 Hi - > From: "Ramanathan Kavasseri" > To: "Randy Presuhn" > Cc: "Disman (E-mail)" > Sent: Tuesday, October 21, 2003 4:46 PM > Subject: Re: [Disman] Fw: training in Minneapolis ... > >>From: > >>To: ; > >>Sent: Thursday, October 16, 2003 2:04 PM > > > > ... > > > >>We will also be presenting a new editor's training session in > >>Minneapolis, as follows: > >> > >> Sunday, November 10, 2003 > ^^^^^^^^^^^^^^^^^^^^^^^^^ > Nov 10th is a Monday, not Sunday. > :-| > > Ram > > >> ========================= > >> 1330-1500 Editor's Training -- Conrad C ... True, but the session is indeed on Sunday, and is still RECOMMENDED. For more information, see http://www.ietf.org/meetings/agenda_58.html Randy From disman-admin@ietf.org Tue Oct 21 20:30:24 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 UAA21309 for ; Tue, 21 Oct 2003 20:30:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6t0-0001E2-Lg; Tue, 21 Oct 2003 20:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6so-0001CL-Ue for disman@optimus.ietf.org; Tue, 21 Oct 2003 20:29:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21238 for ; Tue, 21 Oct 2003 20:29:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC6sm-0005ei-00 for disman@ietf.org; Tue, 21 Oct 2003 20:29:48 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AC6sm-0005ef-00 for disman@ietf.org; Tue, 21 Oct 2003 20:29:48 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AC6sm-0001gy-00; Tue, 21 Oct 2003 17:29:48 -0700 Message-ID: <00af01c39833$b2da2260$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" Cc: "Bert Wijnen" References: <3549C09B853DD5119B540002A52CDD3408F0A895@zcard0ka.ca.nortel.com> Subject: Re: [Disman] varbind offsets in alarm-mib-15 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: Tue, 21 Oct 2003 17:30:30 -0700 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 Oct 21 20:30: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 UAA21324 for ; Tue, 21 Oct 2003 20:30:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6t4-0001FX-3q for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 20:30:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M0U6rP004802 for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 20:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6t4-0001FN-13 for disman-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 20:30:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21250 for ; Tue, 21 Oct 2003 20:29:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC6t1-0005f3-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 20:30:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC6t1-0005f0-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 20:30:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6t0-0001E2-Lg; Tue, 21 Oct 2003 20:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6so-0001CL-Ue for disman@optimus.ietf.org; Tue, 21 Oct 2003 20:29:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21238 for ; Tue, 21 Oct 2003 20:29:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC6sm-0005ei-00 for disman@ietf.org; Tue, 21 Oct 2003 20:29:48 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AC6sm-0005ef-00 for disman@ietf.org; Tue, 21 Oct 2003 20:29:48 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AC6sm-0001gy-00; Tue, 21 Oct 2003 17:29:48 -0700 Message-ID: <00af01c39833$b2da2260$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" Cc: "Bert Wijnen" References: <3549C09B853DD5119B540002A52CDD3408F0A895@zcard0ka.ca.nortel.com> Subject: Re: [Disman] varbind offsets in alarm-mib-15 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: Tue, 21 Oct 2003 17:30:30 -0700 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 Oct 21 20:39: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 UAA21470 for ; Tue, 21 Oct 2003 20:39:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC71h-0003rW-Mk; Tue, 21 Oct 2003 20:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC71M-0003nl-OW for disman@optimus.ietf.org; Tue, 21 Oct 2003 20:38:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21458 for ; Tue, 21 Oct 2003 20:38:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC71K-0005hq-00 for disman@ietf.org; Tue, 21 Oct 2003 20:38:38 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AC71J-0005hn-00 for disman@ietf.org; Tue, 21 Oct 2003 20:38:38 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AC71J-0003r7-00 for disman@ietf.org; Tue, 21 Oct 2003 17:38:37 -0700 Message-ID: <00c101c39834$ee619600$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408F0A8B7@zcard0ka.ca.nortel.com> Subject: Re: [Disman] unthrottleable alarm state change notifications 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: Tue, 21 Oct 2003 17:39:19 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Saturday, October 18, 2003 1:31 PM > Subject: RE: [Disman] unthrottleable alarm state change notifications ... > Again, this is the trade-off that made sense when we last discussed the > problem. Allowing deletion of models with active alarm instances leaves > orphaned active alarms. Not allowing it makes it more difficult to delete > the alarm models. > > There would be three possible ways to address the concern > - Add new instrumentation to manage emergency killing of alarms > - Allow deletion of alarm models at any time, but force the clean up > of any of their active alarms > - Keep exactly as is and make a note in the security considerations. > > I'd like to take the first one off the table as both over engineering and > too big of a change to make at this point. The second one makes me a bit > nervous but I think I could live with it. I suspect one or more of Randy's > hats would object to the third. ... I agree that the first option would be too drastic, and you were right about my reaction to the third. :-) I could live with the second one, but would want some text added to the security considerations section as part of the rationale explaining why the alarmModelRowStatus is considered sensitive, and in discussion of its value in recovering from what could otherwise be pathological misconfigurations. Randy From exim@www1.ietf.org Tue Oct 21 20:39: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 UAA21486 for ; Tue, 21 Oct 2003 20:39:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC71j-0003sK-DN for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 20:39:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M0d3xx014890 for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 20:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC71j-0003s5-6R for disman-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 20:39:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21462 for ; Tue, 21 Oct 2003 20:38:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC71g-0005iA-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 20:39:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC71g-0005i7-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 20:39:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC71h-0003rW-Mk; Tue, 21 Oct 2003 20:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC71M-0003nl-OW for disman@optimus.ietf.org; Tue, 21 Oct 2003 20:38:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21458 for ; Tue, 21 Oct 2003 20:38:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC71K-0005hq-00 for disman@ietf.org; Tue, 21 Oct 2003 20:38:38 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AC71J-0005hn-00 for disman@ietf.org; Tue, 21 Oct 2003 20:38:38 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AC71J-0003r7-00 for disman@ietf.org; Tue, 21 Oct 2003 17:38:37 -0700 Message-ID: <00c101c39834$ee619600$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408F0A8B7@zcard0ka.ca.nortel.com> Subject: Re: [Disman] unthrottleable alarm state change notifications 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: Tue, 21 Oct 2003 17:39:19 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Saturday, October 18, 2003 1:31 PM > Subject: RE: [Disman] unthrottleable alarm state change notifications ... > Again, this is the trade-off that made sense when we last discussed the > problem. Allowing deletion of models with active alarm instances leaves > orphaned active alarms. Not allowing it makes it more difficult to delete > the alarm models. > > There would be three possible ways to address the concern > - Add new instrumentation to manage emergency killing of alarms > - Allow deletion of alarm models at any time, but force the clean up > of any of their active alarms > - Keep exactly as is and make a note in the security considerations. > > I'd like to take the first one off the table as both over engineering and > too big of a change to make at this point. The second one makes me a bit > nervous but I think I could live with it. I suspect one or more of Randy's > hats would object to the third. ... I agree that the first option would be too drastic, and you were right about my reaction to the third. :-) I could live with the second one, but would want some text added to the security considerations section as part of the rationale explaining why the alarmModelRowStatus is considered sensitive, and in discussion of its value in recovering from what could otherwise be pathological misconfigurations. Randy From disman-admin@ietf.org Tue Oct 21 20:53:22 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 UAA21803 for ; Tue, 21 Oct 2003 20:53:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7FF-00081b-76; Tue, 21 Oct 2003 20:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7F2-0007zU-KK for disman@optimus.ietf.org; Tue, 21 Oct 2003 20:52:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21783 for ; Tue, 21 Oct 2003 20:52:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC7F0-0005pV-00 for disman@ietf.org; Tue, 21 Oct 2003 20:52:46 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AC7Ez-0005pS-00 for disman@ietf.org; Tue, 21 Oct 2003 20:52:45 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AC7Ez-00077b-00 for disman@ietf.org; Tue, 21 Oct 2003 17:52:45 -0700 Message-ID: <00e401c39836$e7e36040$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408F0A93D@zcard0ka.ca.nortel.com> Subject: Re: [Disman] ituAlarmGenericModel is redundant? 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: Tue, 21 Oct 2003 17:53:27 -0700 Hi - I think we'll need to keep this one open until we reach a conclusion on 69-1, since the more recent proposals in that thread would change the underlying assumptions about the relationship (or lack thereof) between alarmModelState and ituAlarmPerceivedSeverity. If for each ituAlarmPerceivedSeverity value the corresponding alarmModelState ends up having the same value, then ituAlarmGenericModel would end up being totally redundant. Randy > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Sunday, October 19, 2003 12:09 PM > Subject: RE: [Disman] ituAlarmGenericModel is redundant? > > Hi > > The following is the proposed resolution to Randy-68. Assuming no objection, > this item will is closed with no changes to the draft. > > Sharon > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Thursday, October 16, 2003 12:18 PM > To: Disman (E-mail) > Subject: Re: [Disman] ituAlarmGenericModel is redundant? > > > Hi - > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Wednesday, October 15, 2003 10:14 AM > > Subject: RE: [Disman] ituAlarmGenericModel is redundant? > ... > > The following is the proposed resolution to Randy-68. Assuming no > > objection, this item will is closed with no changes to the draft. > > > > ituAlarmGenericModel is useful, not redundant. > > > > alarmModelTable has > > > > INDEX { alarmListName, alarmModelIndex, alarmModelState } > > > > ituAlarmTable has > > > > INDEX { alarmListName, alarmModelIndex, > > ituAlarmPerceivedSeverity } > > > > Where alarmModelState != ituAlarmPerceivedSeverity > > > > You may be able to figure out which row in the alarmModelTable this > > refers to but maintaining the pointer makes this much faster and > > reliable. > ... > > Ah. Thank you. The purpose of this object is to avoid having to scan the > alarmModelSpecificPointers for a given model to figure out the mapping. > Though I think that's kinda weak, I'm willing to accept the rationale. > > HOWEVER, > > Now I *really* want to know how these itu entries come into (and go out of) > existence as alarm models come and go. > > Randy > > > > From exim@www1.ietf.org Tue Oct 21 20:53: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 UAA21818 for ; Tue, 21 Oct 2003 20:53:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7FH-00082q-Q7 for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 20:53:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M0r3Qd030918 for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 20:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7FH-00082b-Mg for disman-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 20:53:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21790 for ; Tue, 21 Oct 2003 20:52:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC7FF-0005pg-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 20:53:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC7FE-0005pd-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 20:53:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7FF-00081b-76; Tue, 21 Oct 2003 20:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7F2-0007zU-KK for disman@optimus.ietf.org; Tue, 21 Oct 2003 20:52:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21783 for ; Tue, 21 Oct 2003 20:52:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC7F0-0005pV-00 for disman@ietf.org; Tue, 21 Oct 2003 20:52:46 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AC7Ez-0005pS-00 for disman@ietf.org; Tue, 21 Oct 2003 20:52:45 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AC7Ez-00077b-00 for disman@ietf.org; Tue, 21 Oct 2003 17:52:45 -0700 Message-ID: <00e401c39836$e7e36040$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408F0A93D@zcard0ka.ca.nortel.com> Subject: Re: [Disman] ituAlarmGenericModel is redundant? 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: Tue, 21 Oct 2003 17:53:27 -0700 Hi - I think we'll need to keep this one open until we reach a conclusion on 69-1, since the more recent proposals in that thread would change the underlying assumptions about the relationship (or lack thereof) between alarmModelState and ituAlarmPerceivedSeverity. If for each ituAlarmPerceivedSeverity value the corresponding alarmModelState ends up having the same value, then ituAlarmGenericModel would end up being totally redundant. Randy > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Sunday, October 19, 2003 12:09 PM > Subject: RE: [Disman] ituAlarmGenericModel is redundant? > > Hi > > The following is the proposed resolution to Randy-68. Assuming no objection, > this item will is closed with no changes to the draft. > > Sharon > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Thursday, October 16, 2003 12:18 PM > To: Disman (E-mail) > Subject: Re: [Disman] ituAlarmGenericModel is redundant? > > > Hi - > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Wednesday, October 15, 2003 10:14 AM > > Subject: RE: [Disman] ituAlarmGenericModel is redundant? > ... > > The following is the proposed resolution to Randy-68. Assuming no > > objection, this item will is closed with no changes to the draft. > > > > ituAlarmGenericModel is useful, not redundant. > > > > alarmModelTable has > > > > INDEX { alarmListName, alarmModelIndex, alarmModelState } > > > > ituAlarmTable has > > > > INDEX { alarmListName, alarmModelIndex, > > ituAlarmPerceivedSeverity } > > > > Where alarmModelState != ituAlarmPerceivedSeverity > > > > You may be able to figure out which row in the alarmModelTable this > > refers to but maintaining the pointer makes this much faster and > > reliable. > ... > > Ah. Thank you. The purpose of this object is to avoid having to scan the > alarmModelSpecificPointers for a given model to figure out the mapping. > Though I think that's kinda weak, I'm willing to accept the rationale. > > HOWEVER, > > Now I *really* want to know how these itu entries come into (and go out of) > existence as alarm models come and go. > > Randy > > > > From disman-admin@ietf.org Tue Oct 21 21:11:22 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 VAA22320 for ; Tue, 21 Oct 2003 21:11:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7Wg-0004Z3-8j; Tue, 21 Oct 2003 21:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7Wb-0004X3-6X for disman@optimus.ietf.org; Tue, 21 Oct 2003 21:10:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22289 for ; Tue, 21 Oct 2003 21:10:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC7WY-000600-00 for disman@ietf.org; Tue, 21 Oct 2003 21:10:54 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AC7WX-0005zs-00 for disman@ietf.org; Tue, 21 Oct 2003 21:10:53 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AC7WW-0003o2-00 for disman@ietf.org; Tue, 21 Oct 2003 18:10:52 -0700 Message-ID: <00f701c39839$6f9e29a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408F0A8CC@zcard0ka.ca.nortel.com> Subject: Re: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 18:11:34 -0700 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 Tue Oct 21 21:11:24 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 VAA22335 for ; Tue, 21 Oct 2003 21:11:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7Wi-0004bB-FG for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 21:11:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M1B4Ql017671 for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 21:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7Wi-0004aw-BC for disman-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 21:11:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22298 for ; Tue, 21 Oct 2003 21:10:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC7Wf-00060A-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 21:11:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC7Wf-000607-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 21:11:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7Wg-0004Z3-8j; Tue, 21 Oct 2003 21:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7Wb-0004X3-6X for disman@optimus.ietf.org; Tue, 21 Oct 2003 21:10:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22289 for ; Tue, 21 Oct 2003 21:10:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC7WY-000600-00 for disman@ietf.org; Tue, 21 Oct 2003 21:10:54 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AC7WX-0005zs-00 for disman@ietf.org; Tue, 21 Oct 2003 21:10:53 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AC7WW-0003o2-00 for disman@ietf.org; Tue, 21 Oct 2003 18:10:52 -0700 Message-ID: <00f701c39839$6f9e29a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408F0A8CC@zcard0ka.ca.nortel.com> Subject: Re: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 18:11:34 -0700 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 Oct 21 21:45:22 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 VAA23072 for ; Tue, 21 Oct 2003 21:45:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC83Z-0006ti-2W; Tue, 21 Oct 2003 21:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC83H-0006qz-HL for disman@optimus.ietf.org; Tue, 21 Oct 2003 21:44:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23065 for ; Tue, 21 Oct 2003 21:44:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC83E-0006GO-00 for disman@ietf.org; Tue, 21 Oct 2003 21:44:40 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AC83D-0006GL-00 for disman@ietf.org; Tue, 21 Oct 2003 21:44:40 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AC83D-0004Jr-00 for disman@ietf.org; Tue, 21 Oct 2003 18:44:39 -0700 Message-ID: <010001c3983e$283593a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408F0A8D9@zcard0ka.ca.nortel.com> Subject: Re: [Disman] "table wrapping" in alarm MIB -15- 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: Tue, 21 Oct 2003 18:45:22 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Saturday, October 18, 2003 4:21 PM > Subject: RE: [Disman] "table wrapping" in alarm MIB -15- > > Hi > > Ok. I don't understand your issue. There is no maximum because alarms MUST > stay in the table while they are active. There is no wrapping because one of > the indices is DataAndTime so therefore always increasing (unless I'm > missing something). ... Now let's finish the thought: Storage is finite. When the number of active alarms would cause available storage to be exceeded, X happens. What is X? Randy From exim@www1.ietf.org Tue Oct 21 21:45: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 VAA23087 for ; Tue, 21 Oct 2003 21:45:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC83c-0006wM-Jg for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 21:45:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M1j4rQ026672 for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 21:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC83c-0006w7-Co for disman-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 21:45:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23069 for ; Tue, 21 Oct 2003 21:44:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC83Z-0006GY-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 21:45:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC83Z-0006GV-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 21:45:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC83Z-0006ti-2W; Tue, 21 Oct 2003 21:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC83H-0006qz-HL for disman@optimus.ietf.org; Tue, 21 Oct 2003 21:44:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23065 for ; Tue, 21 Oct 2003 21:44:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC83E-0006GO-00 for disman@ietf.org; Tue, 21 Oct 2003 21:44:40 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AC83D-0006GL-00 for disman@ietf.org; Tue, 21 Oct 2003 21:44:40 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AC83D-0004Jr-00 for disman@ietf.org; Tue, 21 Oct 2003 18:44:39 -0700 Message-ID: <010001c3983e$283593a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408F0A8D9@zcard0ka.ca.nortel.com> Subject: Re: [Disman] "table wrapping" in alarm MIB -15- 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: Tue, 21 Oct 2003 18:45:22 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Saturday, October 18, 2003 4:21 PM > Subject: RE: [Disman] "table wrapping" in alarm MIB -15- > > Hi > > Ok. I don't understand your issue. There is no maximum because alarms MUST > stay in the table while they are active. There is no wrapping because one of > the indices is DataAndTime so therefore always increasing (unless I'm > missing something). ... Now let's finish the thought: Storage is finite. When the number of active alarms would cause available storage to be exceeded, X happens. What is X? Randy From disman-admin@ietf.org Tue Oct 21 22:25: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 WAA24088 for ; Tue, 21 Oct 2003 22:25:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC8gH-0001xS-SK; Tue, 21 Oct 2003 22:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC8g3-0001q1-BM for disman@optimus.ietf.org; Tue, 21 Oct 2003 22:24:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24065 for ; Tue, 21 Oct 2003 22:24:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC8fx-0006eQ-00 for disman@ietf.org; Tue, 21 Oct 2003 22:24:41 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AC8fx-0006eN-00 for disman@ietf.org; Tue, 21 Oct 2003 22:24:41 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AC8fw-0006LF-00 for disman@ietf.org; Tue, 21 Oct 2003 19:24:40 -0700 Message-ID: <010b01c39843$bf204620$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408F0A932@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 19:25:23 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Sunday, October 19, 2003 11:32 AM > Subject: RE: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt > > Hi > > Because you can't assume that IP and resourceId is sufficient to identify > the source of an alarm when you support multiple context can you? Presumably that's why an active alarm entry has all of alarmActiveEngineID, alarmActiveEngineAddressType, alarmActiveEngineAddress, and alarmActiveContextName. Since all that information is present in an active alarm entry, I'm still left asking why a management system would need to request that they be put into separate lists in order to "specify alarms from sources in different SNMP contexts". I'm not trying to be dense here. I can understand *other* reasons why an application or security administrator might want various active alarms to go into different lists, but I *don't* see why it would be necessary to do so for purposes of specifying or distinguishing multiple alarm sources. Randy > Sharon > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Friday, October 17, 2003 2:17 PM > To: Disman (E-mail) > Subject: Re: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt > > > Hi - > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Friday, October 17, 2003 4:53 AM > > 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." > ... > > Why would they (want/need) to create separate alarm lists in order to > specify alarms from sources in different SNMP contexts? > > I'm glad the IP business is resolved, but I return to my original question: > > > > 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 Tue Oct 21 22:25:22 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 WAA24103 for ; Tue, 21 Oct 2003 22:25:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC8gK-0001zd-7j for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 22:25:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M2P4Ck007644 for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 22:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC8gJ-0001ys-Vm for disman-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 22:25:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24075 for ; Tue, 21 Oct 2003 22:24:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC8gG-0006en-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 22:25:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC8gG-0006ek-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 22:25:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC8gH-0001xS-SK; Tue, 21 Oct 2003 22:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC8g3-0001q1-BM for disman@optimus.ietf.org; Tue, 21 Oct 2003 22:24:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24065 for ; Tue, 21 Oct 2003 22:24:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC8fx-0006eQ-00 for disman@ietf.org; Tue, 21 Oct 2003 22:24:41 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AC8fx-0006eN-00 for disman@ietf.org; Tue, 21 Oct 2003 22:24:41 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AC8fw-0006LF-00 for disman@ietf.org; Tue, 21 Oct 2003 19:24:40 -0700 Message-ID: <010b01c39843$bf204620$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408F0A932@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Oct 2003 19:25:23 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Sunday, October 19, 2003 11:32 AM > Subject: RE: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt > > Hi > > Because you can't assume that IP and resourceId is sufficient to identify > the source of an alarm when you support multiple context can you? Presumably that's why an active alarm entry has all of alarmActiveEngineID, alarmActiveEngineAddressType, alarmActiveEngineAddress, and alarmActiveContextName. Since all that information is present in an active alarm entry, I'm still left asking why a management system would need to request that they be put into separate lists in order to "specify alarms from sources in different SNMP contexts". I'm not trying to be dense here. I can understand *other* reasons why an application or security administrator might want various active alarms to go into different lists, but I *don't* see why it would be necessary to do so for purposes of specifying or distinguishing multiple alarm sources. Randy > Sharon > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Friday, October 17, 2003 2:17 PM > To: Disman (E-mail) > Subject: Re: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt > > > Hi - > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Friday, October 17, 2003 4:53 AM > > 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." > ... > > Why would they (want/need) to create separate alarm lists in order to > specify alarms from sources in different SNMP contexts? > > I'm glad the IP business is resolved, but I return to my original question: > > > > 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 Tue Oct 21 22:32: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 WAA24339 for ; Tue, 21 Oct 2003 22:32:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC8n4-0004Jz-2G; Tue, 21 Oct 2003 22:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC8m8-0003sZ-4E for disman@optimus.ietf.org; Tue, 21 Oct 2003 22:31:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24285 for ; Tue, 21 Oct 2003 22:30:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC8m4-0006jx-00 for disman@ietf.org; Tue, 21 Oct 2003 22:31:00 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AC8m4-0006jj-00 for disman@ietf.org; Tue, 21 Oct 2003 22:31:00 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9M2UON05144 for ; Tue, 21 Oct 2003 22:30:24 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Oct 2003 22:30:25 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F8D5A9@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, 21 Oct 2003 22:30:23 -0400 Hi 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? Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 21, 2003 9:45 PM To: Disman (E-mail) Subject: Re: [Disman] "table wrapping" in alarm MIB -15- Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Saturday, October 18, 2003 4:21 PM > Subject: RE: [Disman] "table wrapping" in alarm MIB -15- > > Hi > > Ok. I don't understand your issue. There is no maximum because alarms > MUST stay in the table while they are active. There is no wrapping > because one of the indices is DataAndTime so therefore always > increasing (unless I'm missing something). ... Now let's finish the thought: Storage is finite. When the number of active alarms would cause available storage to be exceeded, X happens. What is X? Randy From exim@www1.ietf.org Tue Oct 21 22:32:22 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 WAA24354 for ; Tue, 21 Oct 2003 22:32:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC8n5-0004Lq-N6 for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 22:32:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M2W3OR016720 for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 22:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC8n5-0004Lb-IZ for disman-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 22:32:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24325 for ; Tue, 21 Oct 2003 22:31:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC8n2-0006ke-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 22:32:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC8n1-0006ka-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 22:31:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC8n4-0004Jz-2G; Tue, 21 Oct 2003 22:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC8m8-0003sZ-4E for disman@optimus.ietf.org; Tue, 21 Oct 2003 22:31:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24285 for ; Tue, 21 Oct 2003 22:30:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC8m4-0006jx-00 for disman@ietf.org; Tue, 21 Oct 2003 22:31:00 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AC8m4-0006jj-00 for disman@ietf.org; Tue, 21 Oct 2003 22:31:00 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9M2UON05144 for ; Tue, 21 Oct 2003 22:30:24 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Oct 2003 22:30:25 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F8D5A9@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, 21 Oct 2003 22:30:23 -0400 Hi 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? Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 21, 2003 9:45 PM To: Disman (E-mail) Subject: Re: [Disman] "table wrapping" in alarm MIB -15- Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Saturday, October 18, 2003 4:21 PM > Subject: RE: [Disman] "table wrapping" in alarm MIB -15- > > Hi > > Ok. I don't understand your issue. There is no maximum because alarms > MUST stay in the table while they are active. There is no wrapping > because one of the indices is DataAndTime so therefore always > increasing (unless I'm missing something). ... Now let's finish the thought: Storage is finite. When the number of active alarms would cause available storage to be exceeded, X happens. What is X? Randy From disman-admin@ietf.org Tue Oct 21 23:13: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 XAA25401 for ; Tue, 21 Oct 2003 23:13:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC9Qi-000640-7I; Tue, 21 Oct 2003 23:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC9Qd-000639-5t for disman@optimus.ietf.org; Tue, 21 Oct 2003 23:12:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25384 for ; Tue, 21 Oct 2003 23:12:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC9Qa-00076Y-00 for disman@ietf.org; Tue, 21 Oct 2003 23:12:52 -0400 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by ietf-mx with esmtp (Exim 4.12) id 1AC9Qa-00076V-00 for disman@ietf.org; Tue, 21 Oct 2003 23:12:52 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AC9Qa-0004iV-00 for disman@ietf.org; Tue, 21 Oct 2003 20:12:52 -0700 Message-ID: <000401c3984a$7b261100$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408F8D5A9@zcard0ka.ca.nortel.com> Subject: Re: [Disman] "table wrapping" in alarm MIB -15- 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: Tue, 21 Oct 2003 20:13:35 -0700 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 Oct 21 23:13:22 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 XAA25416 for ; Tue, 21 Oct 2003 23:13:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC9Qk-00065F-NP for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 23:13:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M3D2cT023379 for disman-archive@odin.ietf.org; Tue, 21 Oct 2003 23:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC9Qk-000650-B0 for disman-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 23:13:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25393 for ; Tue, 21 Oct 2003 23:12:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC9Qi-00076j-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 23:13:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC9Qh-00076g-00 for disman-web-archive@ietf.org; Tue, 21 Oct 2003 23:12:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC9Qi-000640-7I; Tue, 21 Oct 2003 23:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC9Qd-000639-5t for disman@optimus.ietf.org; Tue, 21 Oct 2003 23:12:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25384 for ; Tue, 21 Oct 2003 23:12:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC9Qa-00076Y-00 for disman@ietf.org; Tue, 21 Oct 2003 23:12:52 -0400 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by ietf-mx with esmtp (Exim 4.12) id 1AC9Qa-00076V-00 for disman@ietf.org; Tue, 21 Oct 2003 23:12:52 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AC9Qa-0004iV-00 for disman@ietf.org; Tue, 21 Oct 2003 20:12:52 -0700 Message-ID: <000401c3984a$7b261100$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408F8D5A9@zcard0ka.ca.nortel.com> Subject: Re: [Disman] "table wrapping" in alarm MIB -15- 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: Tue, 21 Oct 2003 20:13:35 -0700 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 Oct 22 02:56: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 CAA26804 for ; Wed, 22 Oct 2003 02:56:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACCuX-0004O5-Du; Wed, 22 Oct 2003 02:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACCtu-00049K-48 for disman@optimus.ietf.org; Wed, 22 Oct 2003 02:55:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26787 for ; Wed, 22 Oct 2003 02:55:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACCtq-0001D8-00 for disman@ietf.org; Wed, 22 Oct 2003 02:55:18 -0400 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1ACCtp-0001D5-00 for disman@ietf.org; Wed, 22 Oct 2003 02:55:17 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ACCtq-0001pp-00 for disman@ietf.org; Tue, 21 Oct 2003 23:55:18 -0700 Message-ID: <003701c39869$8eb7bce0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408F0AB05@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: Tue, 21 Oct 2003 23:56:02 -0700 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 Wed Oct 22 02:56:24 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 CAA26819 for ; Wed, 22 Oct 2003 02:56:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACCub-0004Os-C0 for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 02:56:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M6u58g016914 for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 02:56:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACCub-0004Oj-6k for disman-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 02:56:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26791 for ; Wed, 22 Oct 2003 02:55:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACCuX-0001DE-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 02:56:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACCuW-0001DB-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 02:56:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACCuX-0004O5-Du; Wed, 22 Oct 2003 02:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACCtu-00049K-48 for disman@optimus.ietf.org; Wed, 22 Oct 2003 02:55:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26787 for ; Wed, 22 Oct 2003 02:55:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACCtq-0001D8-00 for disman@ietf.org; Wed, 22 Oct 2003 02:55:18 -0400 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1ACCtp-0001D5-00 for disman@ietf.org; Wed, 22 Oct 2003 02:55:17 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ACCtq-0001pp-00 for disman@ietf.org; Tue, 21 Oct 2003 23:55:18 -0700 Message-ID: <003701c39869$8eb7bce0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408F0AB05@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: Tue, 21 Oct 2003 23:56:02 -0700 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 Wed Oct 22 03:06: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 DAA27045 for ; Wed, 22 Oct 2003 03:06:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACD4D-0006dg-NP; Wed, 22 Oct 2003 03:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACD3S-0006TT-EN for disman@optimus.ietf.org; Wed, 22 Oct 2003 03:05:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27013 for ; Wed, 22 Oct 2003 03:05:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACD3O-0001Hp-00 for disman@ietf.org; Wed, 22 Oct 2003 03:05:10 -0400 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1ACD3N-0001Hl-00 for disman@ietf.org; Wed, 22 Oct 2003 03:05:10 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ACD3N-0002sy-00 for disman@ietf.org; Wed, 22 Oct 2003 00:05:09 -0700 Message-ID: <003c01c3986a$eea74200$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408F0A8D2@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Oct 2003 00:05:53 -0700 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 Oct 22 03:06: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 DAA27060 for ; Wed, 22 Oct 2003 03:06:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACD4G-0006fx-9n for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 03:06:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M764qJ025655 for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 03:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACD4F-0006fi-OD for disman-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 03:06:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27030 for ; Wed, 22 Oct 2003 03:05:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACD4B-0001I7-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 03:05:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACD4B-0001I4-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 03:05:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACD4D-0006dg-NP; Wed, 22 Oct 2003 03:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACD3S-0006TT-EN for disman@optimus.ietf.org; Wed, 22 Oct 2003 03:05:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27013 for ; Wed, 22 Oct 2003 03:05:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACD3O-0001Hp-00 for disman@ietf.org; Wed, 22 Oct 2003 03:05:10 -0400 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1ACD3N-0001Hl-00 for disman@ietf.org; Wed, 22 Oct 2003 03:05:10 -0400 Received: from h-68-164-19-32.snvacaid.dynamic.covad.net ([68.164.19.32] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ACD3N-0002sy-00 for disman@ietf.org; Wed, 22 Oct 2003 00:05:09 -0700 Message-ID: <003c01c3986a$eea74200$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408F0A8D2@zcard0ka.ca.nortel.com> Subject: Re: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Oct 2003 00:05:53 -0700 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 Oct 22 04:39: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 EAA29109 for ; Wed, 22 Oct 2003 04:39:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACEWC-0004wf-OD; Wed, 22 Oct 2003 04:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACEVo-0004nN-Lw for disman@optimus.ietf.org; Wed, 22 Oct 2003 04:38:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29085 for ; Wed, 22 Oct 2003 04:38:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACEVl-00026n-00 for disman@ietf.org; Wed, 22 Oct 2003 04:38:33 -0400 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACEVk-00026j-00 for disman@ietf.org; Wed, 22 Oct 2003 04:38:32 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9M8c7FY004798 for ; Wed, 22 Oct 2003 04:38:07 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9M8c5FY004784 for ; Wed, 22 Oct 2003 04:38:06 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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 Message-ID: Thread-Topic: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOYav6TjqA3xEkXQPibHrZVGv3DFwADHPeQ 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: Wed, 22 Oct 2003 10:38:31 +0200 Content-Transfer-Encoding: quoted-printable > > 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 I do not believe this is the case. The text refers to the ITU Alarm MIB, = but does not preclude the third possibility. > 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 See below - Alarm Table can be AUGMETED! > > 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=20 > would be different > from the semantics of augmenting the ITU alarm table, and=20 > that we shouldn't > confuse the two cases. I fail to see where is the confusion. >=20 > Randy >=20 >=20 Regards, Dan >=20 >=20 From exim@www1.ietf.org Wed Oct 22 04:39: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 EAA29124 for ; Wed, 22 Oct 2003 04:39:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACEWI-0004xj-Ir for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 04:39:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M8d6A2019069 for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 04:39:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACEWI-0004xU-CD for disman-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 04:39:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29095 for ; Wed, 22 Oct 2003 04:38:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACEWF-000277-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 04:39:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACEWE-000274-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 04:39:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACEWC-0004wf-OD; Wed, 22 Oct 2003 04:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACEVo-0004nN-Lw for disman@optimus.ietf.org; Wed, 22 Oct 2003 04:38:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29085 for ; Wed, 22 Oct 2003 04:38:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACEVl-00026n-00 for disman@ietf.org; Wed, 22 Oct 2003 04:38:33 -0400 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACEVk-00026j-00 for disman@ietf.org; Wed, 22 Oct 2003 04:38:32 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9M8c7FY004798 for ; Wed, 22 Oct 2003 04:38:07 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9M8c5FY004784 for ; Wed, 22 Oct 2003 04:38:06 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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 Message-ID: Thread-Topic: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOYav6TjqA3xEkXQPibHrZVGv3DFwADHPeQ 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: Wed, 22 Oct 2003 10:38:31 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > 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 I do not believe this is the case. The text refers to the ITU Alarm MIB, = but does not preclude the third possibility. > 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 See below - Alarm Table can be AUGMETED! > > 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=20 > would be different > from the semantics of augmenting the ITU alarm table, and=20 > that we shouldn't > confuse the two cases. I fail to see where is the confusion. >=20 > Randy >=20 >=20 Regards, Dan >=20 >=20 From disman-admin@ietf.org Wed Oct 22 05:59: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 FAA01356 for ; Wed, 22 Oct 2003 05:59:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACFld-0000Rf-Mr; Wed, 22 Oct 2003 05:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACFkf-0000GY-Rq for disman@optimus.ietf.org; Wed, 22 Oct 2003 05:58:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01322 for ; Wed, 22 Oct 2003 05:57:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACFkb-0002qT-00 for disman@ietf.org; Wed, 22 Oct 2003 05:57:58 -0400 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACFkb-0002qP-00 for disman@ietf.org; Wed, 22 Oct 2003 05:57:57 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9M9vPFY012075 for ; Wed, 22 Oct 2003 05:57:25 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9M9vMFY012059 for ; Wed, 22 Oct 2003 05:57:23 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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 Message-ID: Thread-Topic: [Disman] alarm comment 69-1 Thread-Index: AcOYaZznxpOQb0BATR2ppTMNlZcPRgAF7hTQ 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: Wed, 22 Oct 2003 11:57:48 +0200 Content-Transfer-Encoding: quoted-printable Let me try. > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: 22 October, 2003 8:56 AM > To: Disman (E-mail) > Subject: Re: [Disman] alarm comment 69-1 >=20 >=20 > Hi - >=20 > > 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=20 > system when the > > alarmModelTable rows are created. We did have a small hole=20 > in this strategy > > which I've just over-engineered by suggesting we add a=20 > 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=20 > created on systems > > capable of supporting the ITU-T extensions. > > > > alarmModelState =3D 0; ituAlarmPerceivedSeverity =3D 1 > > alarmModelState =3D 1; ituAlarmPerceivedSeverity =3D 2 > > alarmModelState =3D 2; ituAlarmPerceivedSeverity =3D 6 > > alarmModelState =3D 3; ituAlarmPerceivedSeverity =3D 5 > > alarmModelState =3D 4; ituAlarmPerceivedSeverity =3D 4 > > alarmModelState =3D 5; ituAlarmPerceivedSeverity =3D 3 > > > > All other alarmModelState values will not cause the=20 > creation of rows in the > > ituAlarmTable. > ... >=20 > I'm trying to understand the implications of this proposal if=20 > a system supports > other extension models in addition to the ITU-T one. >=20 > 1) what values of alarmModelState will cause=20 > auto-creation of rows in > other extension model MIBs? This is specific to the extension model. A mapping table, as proposed by = Sharon defines what is required for the ITU Alarm model. Other models = would define different mappings.=20 > 2) presumably all models will have an alarmModelState=20 > value of zero. Not clear. Actually the SYNTAX of alarmModelState is Unsigned32 = (1..4294967295). Sharon's proposed mapping table needs probably to be = amended by increase by one all values of alarmModelState. If you mean = that all models will map into cleared state, yes - I agree.=20 > How does a given extension model know whether it is=20 > the one (from > potentially many MIBs) that needs to create a row mapping to > alarmModelState zero? All models will have a mapping into alarm cleared state defined in their = mapping table. =20 > 3) what causes deletion of rows in these tables? for example the removal of a subsystem that supports a specific model in = the system and is the only one that does it. >=20 > Randy >=20 >=20 I hope this helps.=20 Regards, Dan >=20 >=20 From exim@www1.ietf.org Wed Oct 22 05:59: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 FAA01371 for ; Wed, 22 Oct 2003 05:59:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACFlj-0000TW-TZ for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 05:59:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M9x75h001827 for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 05:59:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACFlj-0000TO-JH for disman-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 05:59:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01352 for ; Wed, 22 Oct 2003 05:58:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACFlf-0002rA-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 05:59:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACFlf-0002r7-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 05:59:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACFld-0000Rf-Mr; Wed, 22 Oct 2003 05:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACFkf-0000GY-Rq for disman@optimus.ietf.org; Wed, 22 Oct 2003 05:58:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01322 for ; Wed, 22 Oct 2003 05:57:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACFkb-0002qT-00 for disman@ietf.org; Wed, 22 Oct 2003 05:57:58 -0400 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACFkb-0002qP-00 for disman@ietf.org; Wed, 22 Oct 2003 05:57:57 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9M9vPFY012075 for ; Wed, 22 Oct 2003 05:57:25 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9M9vMFY012059 for ; Wed, 22 Oct 2003 05:57:23 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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 Message-ID: Thread-Topic: [Disman] alarm comment 69-1 Thread-Index: AcOYaZznxpOQb0BATR2ppTMNlZcPRgAF7hTQ 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: Wed, 22 Oct 2003 11:57:48 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Let me try. > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: 22 October, 2003 8:56 AM > To: Disman (E-mail) > Subject: Re: [Disman] alarm comment 69-1 >=20 >=20 > Hi - >=20 > > 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=20 > system when the > > alarmModelTable rows are created. We did have a small hole=20 > in this strategy > > which I've just over-engineered by suggesting we add a=20 > 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=20 > created on systems > > capable of supporting the ITU-T extensions. > > > > alarmModelState =3D 0; ituAlarmPerceivedSeverity =3D 1 > > alarmModelState =3D 1; ituAlarmPerceivedSeverity =3D 2 > > alarmModelState =3D 2; ituAlarmPerceivedSeverity =3D 6 > > alarmModelState =3D 3; ituAlarmPerceivedSeverity =3D 5 > > alarmModelState =3D 4; ituAlarmPerceivedSeverity =3D 4 > > alarmModelState =3D 5; ituAlarmPerceivedSeverity =3D 3 > > > > All other alarmModelState values will not cause the=20 > creation of rows in the > > ituAlarmTable. > ... >=20 > I'm trying to understand the implications of this proposal if=20 > a system supports > other extension models in addition to the ITU-T one. >=20 > 1) what values of alarmModelState will cause=20 > auto-creation of rows in > other extension model MIBs? This is specific to the extension model. A mapping table, as proposed by = Sharon defines what is required for the ITU Alarm model. Other models = would define different mappings.=20 > 2) presumably all models will have an alarmModelState=20 > value of zero. Not clear. Actually the SYNTAX of alarmModelState is Unsigned32 = (1..4294967295). Sharon's proposed mapping table needs probably to be = amended by increase by one all values of alarmModelState. If you mean = that all models will map into cleared state, yes - I agree.=20 > How does a given extension model know whether it is=20 > the one (from > potentially many MIBs) that needs to create a row mapping to > alarmModelState zero? All models will have a mapping into alarm cleared state defined in their = mapping table. =20 > 3) what causes deletion of rows in these tables? for example the removal of a subsystem that supports a specific model in = the system and is the only one that does it. >=20 > Randy >=20 >=20 I hope this helps.=20 Regards, Dan >=20 >=20 From disman-admin@ietf.org Wed Oct 22 08:42:29 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 IAA06024 for ; Wed, 22 Oct 2003 08:42:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIJN-0005bI-Ff; Wed, 22 Oct 2003 08:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIIk-0005U0-Du for disman@optimus.ietf.org; Wed, 22 Oct 2003 08:41:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05995 for ; Wed, 22 Oct 2003 08:41:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACIIj-0004YM-00 for disman@ietf.org; Wed, 22 Oct 2003 08:41:21 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ACIIi-0004Xl-00 for disman@ietf.org; Wed, 22 Oct 2003 08:41:20 -0400 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 h9MCeCs13338 for ; Wed, 22 Oct 2003 08:40:13 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Oct 2003 08:40:13 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F8D65F@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: Wed, 22 Oct 2003 08:40:10 -0400 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 Oct 22 08:42:33 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 IAA06043 for ; Wed, 22 Oct 2003 08:42:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIJW-0005dc-BB for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 08:42:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MCgAOe021668 for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 08:42:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIJW-0005dP-81 for disman-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 08:42:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06011 for ; Wed, 22 Oct 2003 08:41:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACIJU-0004Yk-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 08:42:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACIJU-0004Yh-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 08:42:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIJN-0005bI-Ff; Wed, 22 Oct 2003 08:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIIk-0005U0-Du for disman@optimus.ietf.org; Wed, 22 Oct 2003 08:41:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05995 for ; Wed, 22 Oct 2003 08:41:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACIIj-0004YM-00 for disman@ietf.org; Wed, 22 Oct 2003 08:41:21 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ACIIi-0004Xl-00 for disman@ietf.org; Wed, 22 Oct 2003 08:41:20 -0400 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 h9MCeCs13338 for ; Wed, 22 Oct 2003 08:40:13 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Oct 2003 08:40:13 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F8D65F@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: Wed, 22 Oct 2003 08:40:10 -0400 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 Oct 22 08:53: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 IAA06538 for ; Wed, 22 Oct 2003 08:53:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIU0-0007ks-KS; Wed, 22 Oct 2003 08:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACITx-0007kO-8F for disman@optimus.ietf.org; Wed, 22 Oct 2003 08:52:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06511 for ; Wed, 22 Oct 2003 08:52:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACITv-0004hc-00 for disman@ietf.org; Wed, 22 Oct 2003 08:52:55 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ACITu-0004gh-00 for disman@ietf.org; Wed, 22 Oct 2003 08:52:54 -0400 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 h9MCqLs14470 for ; Wed, 22 Oct 2003 08:52:22 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Oct 2003 08:52:22 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F8D67D@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: Wed, 22 Oct 2003 08:52:21 -0400 Hi > > 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. > ... Not clear. Actually the SYNTAX of alarmModelState is Unsigned32 (1..4294967295). Sharon's proposed mapping table needs probably to be amended by increase by one all values of alarmModelState. If you mean that all models will map into cleared state, yes - I agree. No, that is a typo in my mapping. The numbers in the mapping shoulds start at 1. Sharon From exim@www1.ietf.org Wed Oct 22 08:53:22 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 IAA06553 for ; Wed, 22 Oct 2003 08:53:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIU2-0007lz-GB for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 08:53:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MCr2jB029873 for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 08:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIU2-0007lk-9M for disman-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 08:53:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06519 for ; Wed, 22 Oct 2003 08:52:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACIU0-0004hu-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 08:53:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACIU0-0004hr-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 08:53:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIU0-0007ks-KS; Wed, 22 Oct 2003 08:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACITx-0007kO-8F for disman@optimus.ietf.org; Wed, 22 Oct 2003 08:52:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06511 for ; Wed, 22 Oct 2003 08:52:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACITv-0004hc-00 for disman@ietf.org; Wed, 22 Oct 2003 08:52:55 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ACITu-0004gh-00 for disman@ietf.org; Wed, 22 Oct 2003 08:52:54 -0400 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 h9MCqLs14470 for ; Wed, 22 Oct 2003 08:52:22 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Oct 2003 08:52:22 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F8D67D@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: Wed, 22 Oct 2003 08:52:21 -0400 Hi > > 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. > ... Not clear. Actually the SYNTAX of alarmModelState is Unsigned32 (1..4294967295). Sharon's proposed mapping table needs probably to be amended by increase by one all values of alarmModelState. If you mean that all models will map into cleared state, yes - I agree. No, that is a typo in my mapping. The numbers in the mapping shoulds start at 1. Sharon From disman-admin@ietf.org Wed Oct 22 08:56: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 IAA06771 for ; Wed, 22 Oct 2003 08:56:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIWx-0008Vj-7R; Wed, 22 Oct 2003 08:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIWq-0008SH-NY for disman@optimus.ietf.org; Wed, 22 Oct 2003 08:55:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06734 for ; Wed, 22 Oct 2003 08:55:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACIWp-0004lF-00 for disman@ietf.org; Wed, 22 Oct 2003 08:55:55 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ACIWo-0004l2-00 for disman@ietf.org; Wed, 22 Oct 2003 08:55:54 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9MCtKJ00888 for ; Wed, 22 Oct 2003 08:55:21 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Oct 2003 08:55:21 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F8D688@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: Wed, 22 Oct 2003 08:55:20 -0400 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 Wed Oct 22 08:56:24 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 IAA06786 for ; Wed, 22 Oct 2003 08:56:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIWy-00005h-RD for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 08:56:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MCu4U6000343 for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 08:56:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIWy-00005S-Nl for disman-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 08:56:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06753 for ; Wed, 22 Oct 2003 08:55:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACIWx-0004lm-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 08:56:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACIWw-0004lj-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 08:56:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIWx-0008Vj-7R; Wed, 22 Oct 2003 08:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIWq-0008SH-NY for disman@optimus.ietf.org; Wed, 22 Oct 2003 08:55:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06734 for ; Wed, 22 Oct 2003 08:55:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACIWp-0004lF-00 for disman@ietf.org; Wed, 22 Oct 2003 08:55:55 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ACIWo-0004l2-00 for disman@ietf.org; Wed, 22 Oct 2003 08:55:54 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9MCtKJ00888 for ; Wed, 22 Oct 2003 08:55:21 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Oct 2003 08:55:21 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F8D688@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: Wed, 22 Oct 2003 08:55:20 -0400 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 Wed Oct 22 09:58:32 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 JAA09249 for ; Wed, 22 Oct 2003 09:58:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJUw-0006MD-AT; Wed, 22 Oct 2003 09:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJUe-0006JU-1u for disman@optimus.ietf.org; Wed, 22 Oct 2003 09:57:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09215 for ; Wed, 22 Oct 2003 09:57:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACJUc-0005Xq-00 for disman@ietf.org; Wed, 22 Oct 2003 09:57:42 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ACJUb-0005Xa-00 for disman@ietf.org; Wed, 22 Oct 2003 09:57:41 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9MDv7608824 for ; Wed, 22 Oct 2003 09:57:08 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Oct 2003 09:57:08 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F8D749@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: Wed, 22 Oct 2003 09:57:06 -0400 Hi It's a useful object. The working felt it was a useful object. I think it's a useful object. We've never claimed that there wasn't another means to get this mapping. Why are we suddenly deciding we don't want this object? Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 21, 2003 8:53 PM To: Disman (E-mail) Subject: Re: [Disman] ituAlarmGenericModel is redundant? Hi - I think we'll need to keep this one open until we reach a conclusion on 69-1, since the more recent proposals in that thread would change the underlying assumptions about the relationship (or lack thereof) between alarmModelState and ituAlarmPerceivedSeverity. If for each ituAlarmPerceivedSeverity value the corresponding alarmModelState ends up having the same value, then ituAlarmGenericModel would end up being totally redundant. Randy > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Sunday, October 19, 2003 12:09 PM > Subject: RE: [Disman] ituAlarmGenericModel is redundant? > > Hi > > The following is the proposed resolution to Randy-68. Assuming no > objection, this item will is closed with no changes to the draft. > > Sharon > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Thursday, October 16, 2003 12:18 PM > To: Disman (E-mail) > Subject: Re: [Disman] ituAlarmGenericModel is redundant? > > > Hi - > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Wednesday, October 15, 2003 10:14 AM > > Subject: RE: [Disman] ituAlarmGenericModel is redundant? > ... > > The following is the proposed resolution to Randy-68. Assuming no > > objection, this item will is closed with no changes to the draft. > > > > ituAlarmGenericModel is useful, not redundant. > > > > alarmModelTable has > > > > INDEX { alarmListName, alarmModelIndex, alarmModelState } > > > > ituAlarmTable has > > > > INDEX { alarmListName, alarmModelIndex, > > ituAlarmPerceivedSeverity } > > > > Where alarmModelState != ituAlarmPerceivedSeverity > > > > You may be able to figure out which row in the alarmModelTable this > > refers to but maintaining the pointer makes this much faster and > > reliable. > ... > > Ah. Thank you. The purpose of this object is to avoid having to scan > the alarmModelSpecificPointers for a given model to figure out the > mapping. Though I think that's kinda weak, I'm willing to accept the > rationale. > > HOWEVER, > > Now I *really* want to know how these itu entries come into (and go > out of) existence as alarm models come and go. > > Randy > > > > From exim@www1.ietf.org Wed Oct 22 09:58:35 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 JAA09267 for ; Wed, 22 Oct 2003 09:58:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJV9-0006O8-IW for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 09:58:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MDwFuM024555 for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 09:58:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJV9-0006Ny-EJ for disman-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 09:58:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09224 for ; Wed, 22 Oct 2003 09:58:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACJV6-0005YI-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 09:58:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACJV5-0005YF-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 09:58:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJUw-0006MD-AT; Wed, 22 Oct 2003 09:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJUe-0006JU-1u for disman@optimus.ietf.org; Wed, 22 Oct 2003 09:57:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09215 for ; Wed, 22 Oct 2003 09:57:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACJUc-0005Xq-00 for disman@ietf.org; Wed, 22 Oct 2003 09:57:42 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ACJUb-0005Xa-00 for disman@ietf.org; Wed, 22 Oct 2003 09:57:41 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9MDv7608824 for ; Wed, 22 Oct 2003 09:57:08 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Oct 2003 09:57:08 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3408F8D749@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: Wed, 22 Oct 2003 09:57:06 -0400 Hi It's a useful object. The working felt it was a useful object. I think it's a useful object. We've never claimed that there wasn't another means to get this mapping. Why are we suddenly deciding we don't want this object? Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, October 21, 2003 8:53 PM To: Disman (E-mail) Subject: Re: [Disman] ituAlarmGenericModel is redundant? Hi - I think we'll need to keep this one open until we reach a conclusion on 69-1, since the more recent proposals in that thread would change the underlying assumptions about the relationship (or lack thereof) between alarmModelState and ituAlarmPerceivedSeverity. If for each ituAlarmPerceivedSeverity value the corresponding alarmModelState ends up having the same value, then ituAlarmGenericModel would end up being totally redundant. Randy > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Sunday, October 19, 2003 12:09 PM > Subject: RE: [Disman] ituAlarmGenericModel is redundant? > > Hi > > The following is the proposed resolution to Randy-68. Assuming no > objection, this item will is closed with no changes to the draft. > > Sharon > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Thursday, October 16, 2003 12:18 PM > To: Disman (E-mail) > Subject: Re: [Disman] ituAlarmGenericModel is redundant? > > > Hi - > > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Wednesday, October 15, 2003 10:14 AM > > Subject: RE: [Disman] ituAlarmGenericModel is redundant? > ... > > The following is the proposed resolution to Randy-68. Assuming no > > objection, this item will is closed with no changes to the draft. > > > > ituAlarmGenericModel is useful, not redundant. > > > > alarmModelTable has > > > > INDEX { alarmListName, alarmModelIndex, alarmModelState } > > > > ituAlarmTable has > > > > INDEX { alarmListName, alarmModelIndex, > > ituAlarmPerceivedSeverity } > > > > Where alarmModelState != ituAlarmPerceivedSeverity > > > > You may be able to figure out which row in the alarmModelTable this > > refers to but maintaining the pointer makes this much faster and > > reliable. > ... > > Ah. Thank you. The purpose of this object is to avoid having to scan > the alarmModelSpecificPointers for a given model to figure out the > mapping. Though I think that's kinda weak, I'm willing to accept the > rationale. > > HOWEVER, > > Now I *really* want to know how these itu entries come into (and go > out of) existence as alarm models come and go. > > Randy > > > > From disman-admin@ietf.org Wed Oct 22 12:00: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 MAA15657 for ; Wed, 22 Oct 2003 12:00:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLP1-0003w4-1o; Wed, 22 Oct 2003 12:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLOm-0003to-LW for disman@optimus.ietf.org; Wed, 22 Oct 2003 11:59:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15604 for ; Wed, 22 Oct 2003 11:59:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLOl-00078B-00 for disman@ietf.org; Wed, 22 Oct 2003 11:59:47 -0400 Received: from pintail.mail.pas.earthlink.net ([207.217.120.122]) by ietf-mx with esmtp (Exim 4.12) id 1ACLOk-000783-00 for disman@ietf.org; Wed, 22 Oct 2003 11:59:46 -0400 Received: from h-69-3-246-126.snvacaid.dynamic.covad.net ([69.3.246.126] helo=oemcomputer) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ACLOh-0006ZA-00 for disman@ietf.org; Wed, 22 Oct 2003 08:59:43 -0700 Message-ID: <000801c398b5$9bb2e180$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Oct 2003 09:00:25 -0700 Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Wednesday, October 22, 2003 1:38 AM > Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt > > > > 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. ... > > I believe the proposed text preclude the third possibility > > (c) an entry in the other extension MIB, but not in the > > ITU alarm MIB. > > I do not believe this is the case. The text refers to the ITU Alarm MIB, but does not preclude the third possibility. ??? Sharon's proposed text says that for each row in the alarm model table there will be one row in the ITU alarm model table. (See quote above.) This cannot be true if it is possible for there to be an entry without a corresponding entry 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. > > See below - Alarm Table can be AUGMETED! The point is that if the proposed text is true when it says that an ITU alarm model entry must exist for each generic alarm model entry, then all alarm models will by definition map to ITU models. > > > 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. > > I fail to see where is the confusion. ... The proposed text treats augmentations of the Alarm and ITU alarm tables as equivalent. This is true if all models are required to map to the ITU model if a system implements it. If one doesn't require 1:1 relationship between ITU and generic alarm model entries, i.e., one permits definition of alarm models that do not map to ITU alarm models in a system that supports ITU models, then there is a *big* difference between augmenting the generic tables and augmenting the ITU tables. Example: take a system that supports 3 models: generic, ITU, and AcmeCorp. the system needs to support two kinds of alarms: an ITU-defined one, and an AcmeCorp one. The current proposal requires that we have model table entries like this: acmeentryA1..n -------------- genericentryA1..n --------------- ituentryA1..n acmeentryB1..n --------------- genericentryB1..n --------------- ituentryB1..n or perhaps acmeentryA1..n -------------- genericentryA1..n --------------- ituentryA1..n genericentryB1..n --------------- ituentryB1..n If the AcmeCorp model doesn't map well to ITU model, both of these seem undesirable. Much more reasonable would be: acmeentryA1..n -------------- genericentryA1..n genericentryB1..n --------------- ituentryB1..n which is precluded by the text saying that there must be an ituentry for every generic entry. Randy From exim@www1.ietf.org Wed Oct 22 12:00: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 MAA15676 for ; Wed, 22 Oct 2003 12:00:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLP9-0003yX-4X for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 12:00:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MG0ASq015251 for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 12:00:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLP6-0003xo-WB for disman-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 12:00:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15616 for ; Wed, 22 Oct 2003 11:59:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLP5-00078f-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 12:00:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACLP5-00078c-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 12:00:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLP1-0003w4-1o; Wed, 22 Oct 2003 12:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLOm-0003to-LW for disman@optimus.ietf.org; Wed, 22 Oct 2003 11:59:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15604 for ; Wed, 22 Oct 2003 11:59:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLOl-00078B-00 for disman@ietf.org; Wed, 22 Oct 2003 11:59:47 -0400 Received: from pintail.mail.pas.earthlink.net ([207.217.120.122]) by ietf-mx with esmtp (Exim 4.12) id 1ACLOk-000783-00 for disman@ietf.org; Wed, 22 Oct 2003 11:59:46 -0400 Received: from h-69-3-246-126.snvacaid.dynamic.covad.net ([69.3.246.126] helo=oemcomputer) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ACLOh-0006ZA-00 for disman@ietf.org; Wed, 22 Oct 2003 08:59:43 -0700 Message-ID: <000801c398b5$9bb2e180$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Oct 2003 09:00:25 -0700 Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Wednesday, October 22, 2003 1:38 AM > Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt > > > > 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. ... > > I believe the proposed text preclude the third possibility > > (c) an entry in the other extension MIB, but not in the > > ITU alarm MIB. > > I do not believe this is the case. The text refers to the ITU Alarm MIB, but does not preclude the third possibility. ??? Sharon's proposed text says that for each row in the alarm model table there will be one row in the ITU alarm model table. (See quote above.) This cannot be true if it is possible for there to be an entry without a corresponding entry 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. > > See below - Alarm Table can be AUGMETED! The point is that if the proposed text is true when it says that an ITU alarm model entry must exist for each generic alarm model entry, then all alarm models will by definition map to ITU models. > > > 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. > > I fail to see where is the confusion. ... The proposed text treats augmentations of the Alarm and ITU alarm tables as equivalent. This is true if all models are required to map to the ITU model if a system implements it. If one doesn't require 1:1 relationship between ITU and generic alarm model entries, i.e., one permits definition of alarm models that do not map to ITU alarm models in a system that supports ITU models, then there is a *big* difference between augmenting the generic tables and augmenting the ITU tables. Example: take a system that supports 3 models: generic, ITU, and AcmeCorp. the system needs to support two kinds of alarms: an ITU-defined one, and an AcmeCorp one. The current proposal requires that we have model table entries like this: acmeentryA1..n -------------- genericentryA1..n --------------- ituentryA1..n acmeentryB1..n --------------- genericentryB1..n --------------- ituentryB1..n or perhaps acmeentryA1..n -------------- genericentryA1..n --------------- ituentryA1..n genericentryB1..n --------------- ituentryB1..n If the AcmeCorp model doesn't map well to ITU model, both of these seem undesirable. Much more reasonable would be: acmeentryA1..n -------------- genericentryA1..n genericentryB1..n --------------- ituentryB1..n which is precluded by the text saying that there must be an ituentry for every generic entry. Randy From disman-admin@ietf.org Wed Oct 22 12:24:22 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 MAA16617 for ; Wed, 22 Oct 2003 12:24:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLmD-0007Yp-MY; Wed, 22 Oct 2003 12:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLlm-0007Q2-Dz for disman@optimus.ietf.org; Wed, 22 Oct 2003 12:23:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16556 for ; Wed, 22 Oct 2003 12:23:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLlk-0007RR-00 for disman@ietf.org; Wed, 22 Oct 2003 12:23:32 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACLlj-0007RB-00 for disman@ietf.org; Wed, 22 Oct 2003 12:23:32 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9MGLKJK002737 for ; Wed, 22 Oct 2003 11:21:20 -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 h9MGIdJK029791 for ; Wed, 22 Oct 2003 11:21:18 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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 Message-ID: Thread-Topic: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOYtbS/AsWwseXbSZeGZOkxK/LEdQAAfu6g 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: Wed, 22 Oct 2003 18:20:18 +0200 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: 22 October, 2003 6:00 PM > To: Disman (E-mail) > Subject: Re: [Disman] Section 5.1 in=20 > draft-ietf-disman-alarm-mib-15.txt >=20 >=20 > Hi - >=20 > > From: "Romascanu, Dan (Dan)" > > To: "Randy Presuhn" ; "Disman=20 > (E-mail)" > > Sent: Wednesday, October 22, 2003 1:38 AM > > Subject: RE: [Disman] Section 5.1 in=20 > draft-ietf-disman-alarm-mib-15.txt > > > > > > In the case of the ITU Alarm MIB, for each row in the > > > > alarm model table there is one row in the ITU alarm=20 > model table. > ... > > > I believe the proposed text preclude the third possibility > > > (c) an entry in the other extension MIB, but not in the > > > ITU alarm MIB. > > > > I do not believe this is the case. The text refers to the=20 > ITU Alarm MIB, but does not preclude the third possibility. >=20 > ??? Sharon's proposed text says that for each row in the=20 > alarm model table there > will be one row in the ITU alarm model table. (See quote=20 > above.) This cannot > be true if it is possible for there to be an entry without a=20 > corresponding entry > in the ITU alarm MIB. The quoted text starts with 'In the case of the ITU Alarm MIB' ! Would inserting the adjective 'relevant' between 'each' and 'row' help = clarify? Thanks, Dan From exim@www1.ietf.org Wed Oct 22 12:24:24 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 MAA16632 for ; Wed, 22 Oct 2003 12:24:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLmH-0007ap-12 for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 12:24:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MGO4qn029174 for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 12:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLmG-0007aH-S1 for disman-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 12:24:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16603 for ; Wed, 22 Oct 2003 12:23:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLmF-0007Rl-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 12:24:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACLmE-0007Ri-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 12:24:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLmD-0007Yp-MY; Wed, 22 Oct 2003 12:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLlm-0007Q2-Dz for disman@optimus.ietf.org; Wed, 22 Oct 2003 12:23:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16556 for ; Wed, 22 Oct 2003 12:23:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLlk-0007RR-00 for disman@ietf.org; Wed, 22 Oct 2003 12:23:32 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACLlj-0007RB-00 for disman@ietf.org; Wed, 22 Oct 2003 12:23:32 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9MGLKJK002737 for ; Wed, 22 Oct 2003 11:21:20 -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 h9MGIdJK029791 for ; Wed, 22 Oct 2003 11:21:18 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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 Message-ID: Thread-Topic: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOYtbS/AsWwseXbSZeGZOkxK/LEdQAAfu6g 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: Wed, 22 Oct 2003 18:20:18 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: 22 October, 2003 6:00 PM > To: Disman (E-mail) > Subject: Re: [Disman] Section 5.1 in=20 > draft-ietf-disman-alarm-mib-15.txt >=20 >=20 > Hi - >=20 > > From: "Romascanu, Dan (Dan)" > > To: "Randy Presuhn" ; "Disman=20 > (E-mail)" > > Sent: Wednesday, October 22, 2003 1:38 AM > > Subject: RE: [Disman] Section 5.1 in=20 > draft-ietf-disman-alarm-mib-15.txt > > > > > > In the case of the ITU Alarm MIB, for each row in the > > > > alarm model table there is one row in the ITU alarm=20 > model table. > ... > > > I believe the proposed text preclude the third possibility > > > (c) an entry in the other extension MIB, but not in the > > > ITU alarm MIB. > > > > I do not believe this is the case. The text refers to the=20 > ITU Alarm MIB, but does not preclude the third possibility. >=20 > ??? Sharon's proposed text says that for each row in the=20 > alarm model table there > will be one row in the ITU alarm model table. (See quote=20 > above.) This cannot > be true if it is possible for there to be an entry without a=20 > corresponding entry > in the ITU alarm MIB. The quoted text starts with 'In the case of the ITU Alarm MIB' ! Would inserting the adjective 'relevant' between 'each' and 'row' help = clarify? Thanks, Dan From disman-admin@ietf.org Wed Oct 22 13:21:24 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 NAA18417 for ; Wed, 22 Oct 2003 13:21:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMfN-0006IT-3Z; Wed, 22 Oct 2003 13:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMey-0006Fu-16 for disman@optimus.ietf.org; Wed, 22 Oct 2003 13:20:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18376 for ; Wed, 22 Oct 2003 13:20:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMev-0000Bd-00 for disman@ietf.org; Wed, 22 Oct 2003 13:20:34 -0400 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACMev-0000Ba-00 for disman@ietf.org; Wed, 22 Oct 2003 13:20:33 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9MHK5FY010248 for ; Wed, 22 Oct 2003 13:20:05 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9MHK2FY010205 for ; Wed, 22 Oct 2003 13:20:03 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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 Message-ID: Thread-Topic: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOYtbS/AsWwseXbSZeGZOkxK/LEdQACpsoA 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: Wed, 22 Oct 2003 19:20:28 +0200 Content-Transfer-Encoding: quoted-printable > Much more reasonable would be: >=20 > acmeentryA1..n -------------- genericentryA1..n > genericentryB1..n=20 > --------------- ituentryB1..n >=20 and so it is! actually=20 genericentry A1..n > ituEntry A1'...n' genericentryB1..m > acmeEntryB1'...m' The generic model is generic. Specific models build upon it. there is no = conflict or interlocking. generic model numbers indicate just sorting, = with value 1 being the sole entry with a semantic (clear) Nothing in the text precludes it, but it may be just my poor English! Regards, Dan From exim@www1.ietf.org Wed Oct 22 13:21: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 NAA18433 for ; Wed, 22 Oct 2003 13:21:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMfT-0006Jl-CR for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 13:21:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MHL7uj024279 for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 13:21:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMfT-0006JW-84 for disman-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 13:21:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18401 for ; Wed, 22 Oct 2003 13:20:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMfR-0000Bx-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 13:21:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACMfQ-0000Bu-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 13:21:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMfN-0006IT-3Z; Wed, 22 Oct 2003 13:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMey-0006Fu-16 for disman@optimus.ietf.org; Wed, 22 Oct 2003 13:20:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18376 for ; Wed, 22 Oct 2003 13:20:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMev-0000Bd-00 for disman@ietf.org; Wed, 22 Oct 2003 13:20:34 -0400 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACMev-0000Ba-00 for disman@ietf.org; Wed, 22 Oct 2003 13:20:33 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9MHK5FY010248 for ; Wed, 22 Oct 2003 13:20:05 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9MHK2FY010205 for ; Wed, 22 Oct 2003 13:20:03 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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 Message-ID: Thread-Topic: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOYtbS/AsWwseXbSZeGZOkxK/LEdQACpsoA 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: Wed, 22 Oct 2003 19:20:28 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Much more reasonable would be: >=20 > acmeentryA1..n -------------- genericentryA1..n > genericentryB1..n=20 > --------------- ituentryB1..n >=20 and so it is! actually=20 genericentry A1..n > ituEntry A1'...n' genericentryB1..m > acmeEntryB1'...m' The generic model is generic. Specific models build upon it. there is no = conflict or interlocking. generic model numbers indicate just sorting, = with value 1 being the sole entry with a semantic (clear) Nothing in the text precludes it, but it may be just my poor English! Regards, Dan From disman-admin@ietf.org Wed Oct 22 13:56:22 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 NAA19665 for ; Wed, 22 Oct 2003 13:56:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNDF-0002Xd-3D; Wed, 22 Oct 2003 13:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACND0-0002WQ-PL for disman@optimus.ietf.org; Wed, 22 Oct 2003 13:55:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19604 for ; Wed, 22 Oct 2003 13:55:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACNCx-0000YB-00 for disman@ietf.org; Wed, 22 Oct 2003 13:55:44 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACNCw-0000Y8-00 for disman@ietf.org; Wed, 22 Oct 2003 13:55:43 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9MHrbJK001739 for ; Wed, 22 Oct 2003 12:53:37 -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 h9MHrYJK001714 for ; Wed, 22 Oct 2003 12:53:36 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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] "table wrapping" in alarm MIB -15- Message-ID: Thread-Topic: [Disman] "table wrapping" in alarm MIB -15- Thread-Index: AcOYSm3aL1nvBlW/S+20W5aSNbO4uQAesh3Q 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: Wed, 22 Oct 2003 19:55:38 +0200 Content-Transfer-Encoding: quoted-printable > My personal opinion is that creating no entry, and recording=20 > that fact in a counter is probably > a reasonable solution, but am open to other possibilities. =20 This looks like a solution I can agree with. I guess that this happens = in a zillion of other MIBs that do not happen to go through such a = intensive scrutiny, but it is a good thing to document the behavior, and = explicitly expose it through a Counter object.=20 Regards, Dan From exim@www1.ietf.org Wed Oct 22 13:56:24 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 NAA19681 for ; Wed, 22 Oct 2003 13:56:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNDH-0002Zq-Kz for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 13:56:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MHu3Za009868 for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 13:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNDH-0002Z5-Dv for disman-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 13:56:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19628 for ; Wed, 22 Oct 2003 13:55:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACNDE-0000Yp-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 13:56:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACNDE-0000Ym-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 13:56:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNDF-0002Xd-3D; Wed, 22 Oct 2003 13:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACND0-0002WQ-PL for disman@optimus.ietf.org; Wed, 22 Oct 2003 13:55:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19604 for ; Wed, 22 Oct 2003 13:55:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACNCx-0000YB-00 for disman@ietf.org; Wed, 22 Oct 2003 13:55:44 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACNCw-0000Y8-00 for disman@ietf.org; Wed, 22 Oct 2003 13:55:43 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9MHrbJK001739 for ; Wed, 22 Oct 2003 12:53:37 -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 h9MHrYJK001714 for ; Wed, 22 Oct 2003 12:53:36 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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] "table wrapping" in alarm MIB -15- Message-ID: Thread-Topic: [Disman] "table wrapping" in alarm MIB -15- Thread-Index: AcOYSm3aL1nvBlW/S+20W5aSNbO4uQAesh3Q 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: Wed, 22 Oct 2003 19:55:38 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > My personal opinion is that creating no entry, and recording=20 > that fact in a counter is probably > a reasonable solution, but am open to other possibilities. =20 This looks like a solution I can agree with. I guess that this happens = in a zillion of other MIBs that do not happen to go through such a = intensive scrutiny, but it is a good thing to document the behavior, and = explicitly expose it through a Counter object.=20 Regards, Dan From disman-admin@ietf.org Wed Oct 22 15:05: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 PAA22242 for ; Wed, 22 Oct 2003 15:05:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACOI1-0001tZ-ID; Wed, 22 Oct 2003 15:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACOHd-0001oZ-Fc for disman@optimus.ietf.org; Wed, 22 Oct 2003 15:04:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22136 for ; Wed, 22 Oct 2003 15:04:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACOHZ-0001HL-00 for disman@ietf.org; Wed, 22 Oct 2003 15:04:33 -0400 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACOHZ-0001H7-00 for disman@ietf.org; Wed, 22 Oct 2003 15:04:33 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9MJ44FY023970 for ; Wed, 22 Oct 2003 15:04:04 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9MJ41FY023933 for ; Wed, 22 Oct 2003 15:04:02 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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 3.3.5 of draft-ietf-disman-alarm-mib-15.txt Message-ID: Thread-Topic: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOYQ79eyUCdV1DrQC2BZ86DW5I1aQAi2tWw 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: Wed, 22 Oct 2003 21:04:27 +0200 Content-Transfer-Encoding: quoted-printable Just for curiosity, what are the *other* reasons? Dan >=20 > I'm not trying to be dense here. I can understand *other* reasons > why an application or security administrator might want various > active alarms to go into different lists, but I *don't* see=20 > why it would > be necessary to do so for purposes of specifying or distinguishing > multiple alarm sources. >=20 From exim@www1.ietf.org Wed Oct 22 15:05: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 PAA22260 for ; Wed, 22 Oct 2003 15:05:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACOI5-0001uZ-Pw for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 15:05:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MJ55Hg007346 for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 15:05:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACOI5-0001uP-LW for disman-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 15:05:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22196 for ; Wed, 22 Oct 2003 15:04:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACOI2-0001HZ-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 15:05:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACOI2-0001HW-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 15:05:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACOI1-0001tZ-ID; Wed, 22 Oct 2003 15:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACOHd-0001oZ-Fc for disman@optimus.ietf.org; Wed, 22 Oct 2003 15:04:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22136 for ; Wed, 22 Oct 2003 15:04:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACOHZ-0001HL-00 for disman@ietf.org; Wed, 22 Oct 2003 15:04:33 -0400 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACOHZ-0001H7-00 for disman@ietf.org; Wed, 22 Oct 2003 15:04:33 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9MJ44FY023970 for ; Wed, 22 Oct 2003 15:04:04 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9MJ41FY023933 for ; Wed, 22 Oct 2003 15:04:02 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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 3.3.5 of draft-ietf-disman-alarm-mib-15.txt Message-ID: Thread-Topic: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOYQ79eyUCdV1DrQC2BZ86DW5I1aQAi2tWw 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: Wed, 22 Oct 2003 21:04:27 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Just for curiosity, what are the *other* reasons? Dan >=20 > I'm not trying to be dense here. I can understand *other* reasons > why an application or security administrator might want various > active alarms to go into different lists, but I *don't* see=20 > why it would > be necessary to do so for purposes of specifying or distinguishing > multiple alarm sources. >=20 From disman-admin@ietf.org Wed Oct 22 15:15: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 PAA23342 for ; Wed, 22 Oct 2003 15:15:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACORh-0004wj-Uk; Wed, 22 Oct 2003 15:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACORK-0004me-6I for disman@optimus.ietf.org; Wed, 22 Oct 2003 15:14:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23189 for ; Wed, 22 Oct 2003 15:14:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACORI-0001Ot-00 for disman@ietf.org; Wed, 22 Oct 2003 15:14:36 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACORI-0001Oo-00 for disman@ietf.org; Wed, 22 Oct 2003 15:14:36 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9MJCUJK019791 for ; Wed, 22 Oct 2003 14:12:30 -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 h9MJCRJK019703 for ; Wed, 22 Oct 2003 14:12:28 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt Message-ID: Thread-Topic: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOYOWbAnuXQ8fzlT5C8UaIuRJWjeQAl0neQ 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: Wed, 22 Oct 2003 21:14:31 +0200 Content-Transfer-Encoding: quoted-printable 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=20 > draft-ietf-disman-alarm-mib-15.txt >=20 >=20 > Hi - >=20 > This looks fine to me. I know that in the past there has=20 > been concern about > MIB objects that provide access to community strings,=20 > insecure as they are. > Perhaps we should add words to the security considerations=20 > section explaining > the (perceived) sensitivity of this object, perhaps saying=20 > something like > "Although the use of community strings in SNMPv1 is not=20 > considered an effective > means of providing security, security administrators SHOULD=20 > consider whether > the fact that alarmActiveContextName can reveal community=20 > string values would > make this object sensitive in their environment." (I'm sure=20 > someone can find > better words!) >=20 > Randy >=20 > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Saturday, October 18, 2003 3:15 PM > > Subject: RE: [Disman] alarmActiveContextName in=20 > draft-ietf-disman-alarm-mib-15.txt > > >=20 > > Hi > > > > The following is the proposed resolution to Randy-59 =20 > Assuming no objection, > > this item will be considered closed conditional on the=20 > proposed edit being > > done. > > > > In the description of alarmActiveContextName replace > > > > "The name of the SNMP MIB context from which the=20 > alarm came. > > For SNMPv1 alarms this is the community string=20 > 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=20 > alarm came. > > For SNMPv1 alarms this is the community string=20 > 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" ;=20 > "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=20 > 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=20 > 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=20 > be forwarded? > > > This should not be different? Also, was not SMUX a=20 > 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=20 > heard of it > > before, though if VACM is in use an entry with a zero-length > > vacmAccessContextPrefix and vacmAccessContextMatch equal to=20 > prefix(2) would > > be needed to let these things get to the wire. > > > > The important thing is that the information is supplied by=20 > the subagent, and > > the master agent doesn't know in advance how many different=20 > contexts it > > might see in these notifications. > > > > Furthermore, RFC 2741 is (unfortunately) explicit in=20 > section 6.1.1 in saying > > that > > > > AgentX provides a mechanism for transmitting a context=20 > 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.=20 > There are > > no constraints on its length or contents. > > > > I'm willing to treat non-SnmpAdminString contexts from=20 > subagents as a > > pathological case. Lumping them in with the goofy community=20 > strings and > > mapping them to a zero-length alarmActiveContextName.=20 > (which would be > > indistinguishable from the default context) is probably as=20 > good a solution > > as any. > > > > Sooo, back to the original problem: > > > > I think the first paragraph should state that community or=20 > context values > > that violate the SYNTAX are to be mapped to a zero-length=20 > string. I think > > the second paragraph should be MAY rather than MUST. > > > > Randy > > > > > > > > >=20 >=20 >=20 >=20 From exim@www1.ietf.org Wed Oct 22 15:15: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 PAA23362 for ; Wed, 22 Oct 2003 15:15:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACORj-0004xx-RG for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 15:15:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MJF326019083 for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 15:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACORj-0004xi-NN for disman-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 15:15:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23292 for ; Wed, 22 Oct 2003 15:14:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACORi-0001PK-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 15:15:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACORi-0001PH-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 15:15:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACORh-0004wj-Uk; Wed, 22 Oct 2003 15:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACORK-0004me-6I for disman@optimus.ietf.org; Wed, 22 Oct 2003 15:14:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23189 for ; Wed, 22 Oct 2003 15:14:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACORI-0001Ot-00 for disman@ietf.org; Wed, 22 Oct 2003 15:14:36 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACORI-0001Oo-00 for disman@ietf.org; Wed, 22 Oct 2003 15:14:36 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9MJCUJK019791 for ; Wed, 22 Oct 2003 14:12:30 -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 h9MJCRJK019703 for ; Wed, 22 Oct 2003 14:12:28 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt Message-ID: Thread-Topic: [Disman] alarmActiveContextName in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOYOWbAnuXQ8fzlT5C8UaIuRJWjeQAl0neQ 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: Wed, 22 Oct 2003 21:14:31 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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=20 > draft-ietf-disman-alarm-mib-15.txt >=20 >=20 > Hi - >=20 > This looks fine to me. I know that in the past there has=20 > been concern about > MIB objects that provide access to community strings,=20 > insecure as they are. > Perhaps we should add words to the security considerations=20 > section explaining > the (perceived) sensitivity of this object, perhaps saying=20 > something like > "Although the use of community strings in SNMPv1 is not=20 > considered an effective > means of providing security, security administrators SHOULD=20 > consider whether > the fact that alarmActiveContextName can reveal community=20 > string values would > make this object sensitive in their environment." (I'm sure=20 > someone can find > better words!) >=20 > Randy >=20 > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Saturday, October 18, 2003 3:15 PM > > Subject: RE: [Disman] alarmActiveContextName in=20 > draft-ietf-disman-alarm-mib-15.txt > > >=20 > > Hi > > > > The following is the proposed resolution to Randy-59 =20 > Assuming no objection, > > this item will be considered closed conditional on the=20 > proposed edit being > > done. > > > > In the description of alarmActiveContextName replace > > > > "The name of the SNMP MIB context from which the=20 > alarm came. > > For SNMPv1 alarms this is the community string=20 > 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=20 > alarm came. > > For SNMPv1 alarms this is the community string=20 > 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" ;=20 > "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=20 > 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=20 > 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=20 > be forwarded? > > > This should not be different? Also, was not SMUX a=20 > 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=20 > heard of it > > before, though if VACM is in use an entry with a zero-length > > vacmAccessContextPrefix and vacmAccessContextMatch equal to=20 > prefix(2) would > > be needed to let these things get to the wire. > > > > The important thing is that the information is supplied by=20 > the subagent, and > > the master agent doesn't know in advance how many different=20 > contexts it > > might see in these notifications. > > > > Furthermore, RFC 2741 is (unfortunately) explicit in=20 > section 6.1.1 in saying > > that > > > > AgentX provides a mechanism for transmitting a context=20 > 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.=20 > There are > > no constraints on its length or contents. > > > > I'm willing to treat non-SnmpAdminString contexts from=20 > subagents as a > > pathological case. Lumping them in with the goofy community=20 > strings and > > mapping them to a zero-length alarmActiveContextName.=20 > (which would be > > indistinguishable from the default context) is probably as=20 > good a solution > > as any. > > > > Sooo, back to the original problem: > > > > I think the first paragraph should state that community or=20 > context values > > that violate the SYNTAX are to be mapped to a zero-length=20 > string. I think > > the second paragraph should be MAY rather than MUST. > > > > Randy > > > > > > > > >=20 >=20 >=20 >=20 From disman-admin@ietf.org Wed Oct 22 20:13:34 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 UAA09358 for ; Wed, 22 Oct 2003 20:13:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACT64-00045J-Kf; Wed, 22 Oct 2003 20:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACT5U-00041B-7j for disman@optimus.ietf.org; Wed, 22 Oct 2003 20:12:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09247 for ; Wed, 22 Oct 2003 20:12:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACT5S-0005Xi-00 for disman@ietf.org; Wed, 22 Oct 2003 20:12:22 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1ACT5R-0005XV-00 for disman@ietf.org; Wed, 22 Oct 2003 20:12:21 -0400 Received: from h-69-3-247-33.snvacaid.dynamic.covad.net ([69.3.247.33] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ACT5E-0006gQ-00 for disman@ietf.org; Wed, 22 Oct 2003 17:12:08 -0700 Message-ID: <00a601c398fa$663c9c40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Oct 2003 17:12:51 -0700 Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Wednesday, October 22, 2003 9:20 AM > Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt ... > > > > > 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. > > The quoted text starts with 'In the case of the ITU Alarm MIB' ! That doesn't affect the meaning. > Would inserting the adjective 'relevant' between 'each' and 'row' help clarify? Not really. :-( I think we agree what it's supposed to mean, but the words that are there are say the wrong thing. In the interest of keeping changes to the absolute minimum, I'd be OK with: In the case of the ITU Alarm MIB, for each row in the ITU alarm model table there would be a corresponding row in the alarm model table. or perhaps In the case of the ITU Alarm MIB, for each row in the alarm model table there MAY be one row in the ITU alarm model table. I think we really do agree that the relationship between usable generic and extension model entries isn't 1:1, but rather 1:(0,1), and just need to make sure that the text is sufficiently clear. Randy From exim@www1.ietf.org Wed Oct 22 20:13:36 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 UAA09376 for ; Wed, 22 Oct 2003 20:13:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACT6J-00047B-Gl for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 20:13:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N0DFOR015813 for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 20:13:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACT6J-00046y-CQ for disman-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 20:13:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09321 for ; Wed, 22 Oct 2003 20:13:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACT6H-0005Yo-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 20:13:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACT6G-0005Yj-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 20:13:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACT64-00045J-Kf; Wed, 22 Oct 2003 20:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACT5U-00041B-7j for disman@optimus.ietf.org; Wed, 22 Oct 2003 20:12:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09247 for ; Wed, 22 Oct 2003 20:12:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACT5S-0005Xi-00 for disman@ietf.org; Wed, 22 Oct 2003 20:12:22 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1ACT5R-0005XV-00 for disman@ietf.org; Wed, 22 Oct 2003 20:12:21 -0400 Received: from h-69-3-247-33.snvacaid.dynamic.covad.net ([69.3.247.33] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ACT5E-0006gQ-00 for disman@ietf.org; Wed, 22 Oct 2003 17:12:08 -0700 Message-ID: <00a601c398fa$663c9c40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Oct 2003 17:12:51 -0700 Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Wednesday, October 22, 2003 9:20 AM > Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt ... > > > > > 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. > > The quoted text starts with 'In the case of the ITU Alarm MIB' ! That doesn't affect the meaning. > Would inserting the adjective 'relevant' between 'each' and 'row' help clarify? Not really. :-( I think we agree what it's supposed to mean, but the words that are there are say the wrong thing. In the interest of keeping changes to the absolute minimum, I'd be OK with: In the case of the ITU Alarm MIB, for each row in the ITU alarm model table there would be a corresponding row in the alarm model table. or perhaps In the case of the ITU Alarm MIB, for each row in the alarm model table there MAY be one row in the ITU alarm model table. I think we really do agree that the relationship between usable generic and extension model entries isn't 1:1, but rather 1:(0,1), and just need to make sure that the text is sufficiently clear. Randy From disman-admin@ietf.org Wed Oct 22 20:22: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 UAA10148 for ; Wed, 22 Oct 2003 20:22:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACTEm-0005UK-Ir; Wed, 22 Oct 2003 20:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACTDn-0005L7-Jn for disman@optimus.ietf.org; Wed, 22 Oct 2003 20:21:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09917 for ; Wed, 22 Oct 2003 20:20:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACTDZ-0005hz-00 for disman@ietf.org; Wed, 22 Oct 2003 20:20:45 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1ACTDY-0005hw-00 for disman@ietf.org; Wed, 22 Oct 2003 20:20:44 -0400 Received: from h-69-3-247-33.snvacaid.dynamic.covad.net ([69.3.247.33] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ACTDY-0000z9-00 for disman@ietf.org; Wed, 22 Oct 2003 17:20:44 -0700 Message-ID: <00ab01c398fb$99ad71c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Oct 2003 17:21:27 -0700 Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Wednesday, October 22, 2003 12:04 PM > Subject: RE: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt > > Just for curiosity, what are the *other* reasons? ... For example, one might consider security alarms sensitive. VACM and RFC 3414's operation can take care of segregating these by name. Having them go into correspondingly named lists in the alarm MIB means keeping security alarms away from prying eyes, while still allowing others access to other alarms, is easy to set up with VACM. For example, one might want to segregate alarms by customer, so that one customer cannot find out about another customer's alarms. VACM + named alarm lists makes both of these relatively easy to do, just as with logging and notification destination selection. Randy From exim@www1.ietf.org Wed Oct 22 20:22: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 UAA10164 for ; Wed, 22 Oct 2003 20:22:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACTEo-0005W2-Iq for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 20:22:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N0M2s8021196 for disman-archive@odin.ietf.org; Wed, 22 Oct 2003 20:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACTEo-0005Vn-ES for disman-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 20:22:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10081 for ; Wed, 22 Oct 2003 20:21:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACTEl-0005lG-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 20:22:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACTEl-0005lD-00 for disman-web-archive@ietf.org; Wed, 22 Oct 2003 20:21:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACTEm-0005UK-Ir; Wed, 22 Oct 2003 20:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACTDn-0005L7-Jn for disman@optimus.ietf.org; Wed, 22 Oct 2003 20:21:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09917 for ; Wed, 22 Oct 2003 20:20:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACTDZ-0005hz-00 for disman@ietf.org; Wed, 22 Oct 2003 20:20:45 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1ACTDY-0005hw-00 for disman@ietf.org; Wed, 22 Oct 2003 20:20:44 -0400 Received: from h-69-3-247-33.snvacaid.dynamic.covad.net ([69.3.247.33] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ACTDY-0000z9-00 for disman@ietf.org; Wed, 22 Oct 2003 17:20:44 -0700 Message-ID: <00ab01c398fb$99ad71c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Oct 2003 17:21:27 -0700 Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Wednesday, October 22, 2003 12:04 PM > Subject: RE: [Disman] Section 3.3.5 of draft-ietf-disman-alarm-mib-15.txt > > Just for curiosity, what are the *other* reasons? ... For example, one might consider security alarms sensitive. VACM and RFC 3414's operation can take care of segregating these by name. Having them go into correspondingly named lists in the alarm MIB means keeping security alarms away from prying eyes, while still allowing others access to other alarms, is easy to set up with VACM. For example, one might want to segregate alarms by customer, so that one customer cannot find out about another customer's alarms. VACM + named alarm lists makes both of these relatively easy to do, just as with logging and notification destination selection. Randy From disman-admin@ietf.org Thu Oct 23 03:35: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 DAA06705 for ; Thu, 23 Oct 2003 03:35:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZzq-0005ze-Fv; Thu, 23 Oct 2003 03:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZzE-0005u8-8i for disman@optimus.ietf.org; Thu, 23 Oct 2003 03:34:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06686 for ; Thu, 23 Oct 2003 03:34:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZzB-0002xl-00 for disman@ietf.org; Thu, 23 Oct 2003 03:34:21 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACZzB-0002xi-00 for disman@ietf.org; Thu, 23 Oct 2003 03:34:21 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9N7WGJK006314 for ; Thu, 23 Oct 2003 02:32:16 -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 h9N7WEJK006293 for ; Thu, 23 Oct 2003 02:32:15 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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 Message-ID: Thread-Topic: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOY+pkmfId/OlNFSNmxG6hohh6FFwAPMt+Q 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: Thu, 23 Oct 2003 09:34:19 +0200 Content-Transfer-Encoding: quoted-printable > > > > > > In the case of the ITU Alarm MIB, for each row in the > > > > > > alarm model table there is one row in the ITU=20 > alarm model table. > > > > The quoted text starts with 'In the case of the ITU Alarm MIB' ! >=20 > That doesn't affect the meaning. >=20 > > Would inserting the adjective 'relevant' between 'each' and=20 > 'row' help clarify? >=20 > Not really. :-( I think we agree what it's supposed to=20 > mean, but the words that > are there are say the wrong thing. In the interest of keeping=20 > changes to the absolute > minimum, I'd be OK with: >=20 > In the case of the ITU Alarm MIB, for each row in the ITU=20 > alarm model table > there would be a corresponding row in the alarm model table. >=20 > or perhaps >=20 > In the case of the ITU Alarm MIB, for each row in the alarm=20 > model table there > MAY be one row in the ITU alarm model table. I am fine with any of the two texts that you are proposing. I thing that = they say EXACTLY the same thing as the original text with 'relevant' = inserted, but English is only my third language.=20 >=20 > I think we really do agree that the relationship between=20 > usable generic and > extension model entries isn't 1:1, but rather 1:(0,1), and=20 > just need to make sure > that the text is sufficiently clear. Indeed. >=20 > Randy >=20 >=20 Case closed on this one? Regards, Dan >=20 >=20 From exim@www1.ietf.org Thu Oct 23 03:35: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 DAA06721 for ; Thu, 23 Oct 2003 03:35:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZzt-00061I-Pn for disman-archive@odin.ietf.org; Thu, 23 Oct 2003 03:35:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N7Z5LV023134 for disman-archive@odin.ietf.org; Thu, 23 Oct 2003 03:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZzt-000613-As for disman-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 03:35:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06700 for ; Thu, 23 Oct 2003 03:34:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZzq-0002y8-00 for disman-web-archive@ietf.org; Thu, 23 Oct 2003 03:35:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACZzq-0002y5-00 for disman-web-archive@ietf.org; Thu, 23 Oct 2003 03:35:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZzq-0005ze-Fv; Thu, 23 Oct 2003 03:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZzE-0005u8-8i for disman@optimus.ietf.org; Thu, 23 Oct 2003 03:34:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06686 for ; Thu, 23 Oct 2003 03:34:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZzB-0002xl-00 for disman@ietf.org; Thu, 23 Oct 2003 03:34:21 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACZzB-0002xi-00 for disman@ietf.org; Thu, 23 Oct 2003 03:34:21 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9N7WGJK006314 for ; Thu, 23 Oct 2003 02:32:16 -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 h9N7WEJK006293 for ; Thu, 23 Oct 2003 02:32:15 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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 Message-ID: Thread-Topic: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt Thread-Index: AcOY+pkmfId/OlNFSNmxG6hohh6FFwAPMt+Q 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: Thu, 23 Oct 2003 09:34:19 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > > > > > In the case of the ITU Alarm MIB, for each row in the > > > > > > alarm model table there is one row in the ITU=20 > alarm model table. > > > > The quoted text starts with 'In the case of the ITU Alarm MIB' ! >=20 > That doesn't affect the meaning. >=20 > > Would inserting the adjective 'relevant' between 'each' and=20 > 'row' help clarify? >=20 > Not really. :-( I think we agree what it's supposed to=20 > mean, but the words that > are there are say the wrong thing. In the interest of keeping=20 > changes to the absolute > minimum, I'd be OK with: >=20 > In the case of the ITU Alarm MIB, for each row in the ITU=20 > alarm model table > there would be a corresponding row in the alarm model table. >=20 > or perhaps >=20 > In the case of the ITU Alarm MIB, for each row in the alarm=20 > model table there > MAY be one row in the ITU alarm model table. I am fine with any of the two texts that you are proposing. I thing that = they say EXACTLY the same thing as the original text with 'relevant' = inserted, but English is only my third language.=20 >=20 > I think we really do agree that the relationship between=20 > usable generic and > extension model entries isn't 1:1, but rather 1:(0,1), and=20 > just need to make sure > that the text is sufficiently clear. Indeed. >=20 > Randy >=20 >=20 Case closed on this one? Regards, Dan >=20 >=20 From disman-admin@ietf.org Thu Oct 23 09:28: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 JAA18390 for ; Thu, 23 Oct 2003 09:28:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfVR-00015p-97; Thu, 23 Oct 2003 09:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfUc-0000xi-VH for disman@optimus.ietf.org; Thu, 23 Oct 2003 09:27:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18326 for ; Thu, 23 Oct 2003 09:27:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACfUb-0007FJ-00 for disman@ietf.org; Thu, 23 Oct 2003 09:27:09 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACfUa-0007FG-00 for disman@ietf.org; Thu, 23 Oct 2003 09:27:08 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9NDP1JK014889 for ; Thu, 23 Oct 2003 08:25:02 -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 h9NDOxJK014829 for ; Thu, 23 Oct 2003 08:25:00 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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] unthrottleable alarm state change notifications Message-ID: Thread-Topic: [Disman] unthrottleable alarm state change notifications Thread-Index: AcOYNO6di3pnJqqGTE6V3VLeOLyJbgBMf4lA 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: Thu, 23 Oct 2003 15:27:03 +0200 Content-Transfer-Encoding: quoted-printable >=20 > Hi - >=20 > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Saturday, October 18, 2003 1:31 PM > > Subject: RE: [Disman] unthrottleable alarm state change=20 > notifications > ... > > Again, this is the trade-off that made sense when we last=20 > discussed the > > problem. Allowing deletion of models with active alarm=20 > instances leaves > > orphaned active alarms. Not allowing it makes it more=20 > difficult to delete > > the alarm models. > > > > There would be three possible ways to address the concern > > - Add new instrumentation to manage emergency killing of alarms > > - Allow deletion of alarm models at any time, but force the clean up > > of any of their active alarms > > - Keep exactly as is and make a note in the security considerations. > > > > I'd like to take the first one off the table as both over=20 > engineering and > > too big of a change to make at this point. The second one=20 > makes me a bit > > nervous but I think I could live with it. I suspect one or=20 > more of Randy's > > hats would object to the third. > ... >=20 > I agree that the first option would be too drastic, and you=20 > were right about > my reaction to the third. :-) >=20 > I could live with the second one, but would want some text=20 > added to the > security considerations section as part of the rationale=20 > explaining why the > alarmModelRowStatus is considered sensitive, and in discussion of its > value in recovering from what could otherwise be pathological=20 > misconfigurations. 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.' >=20 > Randy >=20 >=20 >=20 >=20 From exim@www1.ietf.org Thu Oct 23 09:28: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 JAA18405 for ; Thu, 23 Oct 2003 09:28:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfVV-00017b-0K for disman-archive@odin.ietf.org; Thu, 23 Oct 2003 09:28:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NDS45q004305 for disman-archive@odin.ietf.org; Thu, 23 Oct 2003 09:28:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfVU-00017M-QX for disman-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 09:28:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18369 for ; Thu, 23 Oct 2003 09:27:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACfVT-0007Fl-00 for disman-web-archive@ietf.org; Thu, 23 Oct 2003 09:28:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACfVS-0007Fi-00 for disman-web-archive@ietf.org; Thu, 23 Oct 2003 09:28:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfVR-00015p-97; Thu, 23 Oct 2003 09:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfUc-0000xi-VH for disman@optimus.ietf.org; Thu, 23 Oct 2003 09:27:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18326 for ; Thu, 23 Oct 2003 09:27:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACfUb-0007FJ-00 for disman@ietf.org; Thu, 23 Oct 2003 09:27:09 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACfUa-0007FG-00 for disman@ietf.org; Thu, 23 Oct 2003 09:27:08 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9NDP1JK014889 for ; Thu, 23 Oct 2003 08:25:02 -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 h9NDOxJK014829 for ; Thu, 23 Oct 2003 08:25:00 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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] unthrottleable alarm state change notifications Message-ID: Thread-Topic: [Disman] unthrottleable alarm state change notifications Thread-Index: AcOYNO6di3pnJqqGTE6V3VLeOLyJbgBMf4lA 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: Thu, 23 Oct 2003 15:27:03 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > Hi - >=20 > > From: "Sharon Chisholm" > > To: "Disman (E-mail)" > > Sent: Saturday, October 18, 2003 1:31 PM > > Subject: RE: [Disman] unthrottleable alarm state change=20 > notifications > ... > > Again, this is the trade-off that made sense when we last=20 > discussed the > > problem. Allowing deletion of models with active alarm=20 > instances leaves > > orphaned active alarms. Not allowing it makes it more=20 > difficult to delete > > the alarm models. > > > > There would be three possible ways to address the concern > > - Add new instrumentation to manage emergency killing of alarms > > - Allow deletion of alarm models at any time, but force the clean up > > of any of their active alarms > > - Keep exactly as is and make a note in the security considerations. > > > > I'd like to take the first one off the table as both over=20 > engineering and > > too big of a change to make at this point. The second one=20 > makes me a bit > > nervous but I think I could live with it. I suspect one or=20 > more of Randy's > > hats would object to the third. > ... >=20 > I agree that the first option would be too drastic, and you=20 > were right about > my reaction to the third. :-) >=20 > I could live with the second one, but would want some text=20 > added to the > security considerations section as part of the rationale=20 > explaining why the > alarmModelRowStatus is considered sensitive, and in discussion of its > value in recovering from what could otherwise be pathological=20 > misconfigurations. 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.' >=20 > Randy >=20 >=20 >=20 >=20 From disman-admin@ietf.org Thu Oct 23 13:42:24 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 NAA08718 for ; Thu, 23 Oct 2003 13:42:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjTF-0000KU-W0; Thu, 23 Oct 2003 13:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjSh-0000B3-Hr for disman@optimus.ietf.org; Thu, 23 Oct 2003 13:41:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08694 for ; Thu, 23 Oct 2003 13:41:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjSf-0005Oz-00 for disman@ietf.org; Thu, 23 Oct 2003 13:41:25 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1ACjSe-0005Of-00 for disman@ietf.org; Thu, 23 Oct 2003 13:41:25 -0400 Received: from h-68-164-86-56.snvacaid.dynamic.covad.net ([68.164.86.56] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ACjSP-0005GC-00 for disman@ietf.org; Thu, 23 Oct 2003 10:41:09 -0700 Message-ID: <007801c3998c$f2e87e60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Fw: I-D ACTION:draft-adwankar-netconf-symple-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, 23 Oct 2003 10:41:54 -0700 Hi - This will probably be of interest to disman WG members. Randy > From: > To: > Cc: > Sent: Thursday, October 23, 2003 6:24 AM > Subject: I-D ACTION:draft-adwankar-netconf-symple-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : SYMPLE Scripting Protocol and architecture for > seamless management of XML based mobile devices and > SNMP based devices > Author(s) : S. Adwankar, et. al. > Filename : draft-adwankar-netconf-symple-00.txt > Pages : 27 > Date : 2003-10-22 > > There is a need for XML based scripting mechanism that allows > ease of script construction and delegation with standardized > mechanism. A management script composed of a set of instructions > will allow periodic, coordinated and policy based management action. > This memo describes a method of expressing management script and > architecture for seamless management of XML based mobile devices > along with SNMP based devices. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-adwankar-netconf-symple-00.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-adwankar-netconf-symple-00.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-adwankar-netconf-symple-00.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. > From exim@www1.ietf.org Thu Oct 23 13:42: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 NAA08733 for ; Thu, 23 Oct 2003 13:42:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjTJ-0000MA-Gk for disman-archive@odin.ietf.org; Thu, 23 Oct 2003 13:42:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NHg5sB001364 for disman-archive@odin.ietf.org; Thu, 23 Oct 2003 13:42:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjTJ-0000Lv-CK for disman-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 13:42:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08705 for ; Thu, 23 Oct 2003 13:41:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjTH-0005PP-00 for disman-web-archive@ietf.org; Thu, 23 Oct 2003 13:42:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACjTG-0005PM-00 for disman-web-archive@ietf.org; Thu, 23 Oct 2003 13:42:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjTF-0000KU-W0; Thu, 23 Oct 2003 13:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjSh-0000B3-Hr for disman@optimus.ietf.org; Thu, 23 Oct 2003 13:41:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08694 for ; Thu, 23 Oct 2003 13:41:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjSf-0005Oz-00 for disman@ietf.org; Thu, 23 Oct 2003 13:41:25 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1ACjSe-0005Of-00 for disman@ietf.org; Thu, 23 Oct 2003 13:41:25 -0400 Received: from h-68-164-86-56.snvacaid.dynamic.covad.net ([68.164.86.56] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ACjSP-0005GC-00 for disman@ietf.org; Thu, 23 Oct 2003 10:41:09 -0700 Message-ID: <007801c3998c$f2e87e60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Fw: I-D ACTION:draft-adwankar-netconf-symple-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, 23 Oct 2003 10:41:54 -0700 Hi - This will probably be of interest to disman WG members. Randy > From: > To: > Cc: > Sent: Thursday, October 23, 2003 6:24 AM > Subject: I-D ACTION:draft-adwankar-netconf-symple-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : SYMPLE Scripting Protocol and architecture for > seamless management of XML based mobile devices and > SNMP based devices > Author(s) : S. Adwankar, et. al. > Filename : draft-adwankar-netconf-symple-00.txt > Pages : 27 > Date : 2003-10-22 > > There is a need for XML based scripting mechanism that allows > ease of script construction and delegation with standardized > mechanism. A management script composed of a set of instructions > will allow periodic, coordinated and policy based management action. > This memo describes a method of expressing management script and > architecture for seamless management of XML based mobile devices > along with SNMP based devices. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-adwankar-netconf-symple-00.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-adwankar-netconf-symple-00.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-adwankar-netconf-symple-00.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. > From disman-admin@ietf.org Thu Oct 23 13:47: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 NAA08861 for ; Thu, 23 Oct 2003 13:47:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjY4-0001Eb-R7; Thu, 23 Oct 2003 13:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjXy-0001DV-Lm for disman@optimus.ietf.org; Thu, 23 Oct 2003 13:46:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08832 for ; Thu, 23 Oct 2003 13:46:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjXw-0005T2-00 for disman@ietf.org; Thu, 23 Oct 2003 13:46:52 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1ACjXv-0005Sy-00 for disman@ietf.org; Thu, 23 Oct 2003 13:46:51 -0400 Received: from h-68-164-86-56.snvacaid.dynamic.covad.net ([68.164.86.56] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ACjXv-0006Ye-00 for disman@ietf.org; Thu, 23 Oct 2003 10:46:51 -0700 Message-ID: <008601c3998d$bf001d00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] unthrottleable alarm state change notifications 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: Thu, 23 Oct 2003 10:47:36 -0700 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 Thu Oct 23 13:47:22 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 NAA08878 for ; Thu, 23 Oct 2003 13:47:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjY6-0001FO-2q for disman-archive@odin.ietf.org; Thu, 23 Oct 2003 13:47:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NHl2xu004788 for disman-archive@odin.ietf.org; Thu, 23 Oct 2003 13:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjY5-0001F9-Ub for disman-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 13:47:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08837 for ; Thu, 23 Oct 2003 13:46:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjY3-0005TB-00 for disman-web-archive@ietf.org; Thu, 23 Oct 2003 13:46:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACjY3-0005T8-00 for disman-web-archive@ietf.org; Thu, 23 Oct 2003 13:46:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjY4-0001Eb-R7; Thu, 23 Oct 2003 13:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjXy-0001DV-Lm for disman@optimus.ietf.org; Thu, 23 Oct 2003 13:46:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08832 for ; Thu, 23 Oct 2003 13:46:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjXw-0005T2-00 for disman@ietf.org; Thu, 23 Oct 2003 13:46:52 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1ACjXv-0005Sy-00 for disman@ietf.org; Thu, 23 Oct 2003 13:46:51 -0400 Received: from h-68-164-86-56.snvacaid.dynamic.covad.net ([68.164.86.56] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ACjXv-0006Ye-00 for disman@ietf.org; Thu, 23 Oct 2003 10:46:51 -0700 Message-ID: <008601c3998d$bf001d00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] unthrottleable alarm state change notifications 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: Thu, 23 Oct 2003 10:47:36 -0700 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 Thu Oct 23 14:01: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 OAA09470 for ; Thu, 23 Oct 2003 14:01:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjle-0003ge-5O; Thu, 23 Oct 2003 14:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjl1-0003aW-9Z for disman@optimus.ietf.org; Thu, 23 Oct 2003 14:00:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09387 for ; Thu, 23 Oct 2003 14:00:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjky-0005cQ-00 for disman@ietf.org; Thu, 23 Oct 2003 14:00:20 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1ACjky-0005cN-00 for disman@ietf.org; Thu, 23 Oct 2003 14:00:20 -0400 Received: from h-68-164-86-56.snvacaid.dynamic.covad.net ([68.164.86.56] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ACjkx-0001pW-00 for disman@ietf.org; Thu, 23 Oct 2003 11:00:19 -0700 Message-ID: <022b01c3998f$a0505c60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408F8D749@zcard0ka.ca.nortel.com> Subject: Re: [Disman] ituAlarmGenericModel is redundant? 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: Thu, 23 Oct 2003 11:01:04 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Wednesday, October 22, 2003 6:57 AM > Subject: RE: [Disman] ituAlarmGenericModel is redundant? ... > It's a useful object. The working felt it was a useful object. I think it's > a useful object. We've never claimed that there wasn't another means to get > this mapping. Why are we suddenly deciding we don't want this object? ... Redundant objects have long been discouraged. If you believe that there is overwhelming support to retain it, then I suggest we follow Bert's advice from the Mreview mailing list: | In general I discuourage people to create redundant MIB | objects. But ... if they have good reasons, I think we | should try to understand them and make them document it | in the MIB documents, preferebaly in the "duplicate" object | DESCRIPTION clause. Randy From exim@www1.ietf.org Thu Oct 23 14:01: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 OAA09486 for ; Thu, 23 Oct 2003 14:01:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjll-0003k1-OX for disman-archive@odin.ietf.org; Thu, 23 Oct 2003 14:01:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NI19kO014371 for disman-archive@odin.ietf.org; Thu, 23 Oct 2003 14:01:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjll-0003jS-G8 for disman-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 14:01:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09452 for ; Thu, 23 Oct 2003 14:00:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjlh-0005dI-00 for disman-web-archive@ietf.org; Thu, 23 Oct 2003 14:01:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACjlh-0005dF-00 for disman-web-archive@ietf.org; Thu, 23 Oct 2003 14:01:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjle-0003ge-5O; Thu, 23 Oct 2003 14:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjl1-0003aW-9Z for disman@optimus.ietf.org; Thu, 23 Oct 2003 14:00:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09387 for ; Thu, 23 Oct 2003 14:00:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjky-0005cQ-00 for disman@ietf.org; Thu, 23 Oct 2003 14:00:20 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1ACjky-0005cN-00 for disman@ietf.org; Thu, 23 Oct 2003 14:00:20 -0400 Received: from h-68-164-86-56.snvacaid.dynamic.covad.net ([68.164.86.56] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ACjkx-0001pW-00 for disman@ietf.org; Thu, 23 Oct 2003 11:00:19 -0700 Message-ID: <022b01c3998f$a0505c60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD3408F8D749@zcard0ka.ca.nortel.com> Subject: Re: [Disman] ituAlarmGenericModel is redundant? 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: Thu, 23 Oct 2003 11:01:04 -0700 Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Wednesday, October 22, 2003 6:57 AM > Subject: RE: [Disman] ituAlarmGenericModel is redundant? ... > It's a useful object. The working felt it was a useful object. I think it's > a useful object. We've never claimed that there wasn't another means to get > this mapping. Why are we suddenly deciding we don't want this object? ... Redundant objects have long been discouraged. If you believe that there is overwhelming support to retain it, then I suggest we follow Bert's advice from the Mreview mailing list: | In general I discuourage people to create redundant MIB | objects. But ... if they have good reasons, I think we | should try to understand them and make them document it | in the MIB documents, preferebaly in the "duplicate" object | DESCRIPTION clause. Randy From disman-admin@ietf.org Fri Oct 24 15:06: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 PAA23774 for ; Fri, 24 Oct 2003 15:06:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7G5-0002YB-1u; Fri, 24 Oct 2003 15:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7Fr-0002Um-0q for disman@optimus.ietf.org; Fri, 24 Oct 2003 15:05:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23662 for ; Fri, 24 Oct 2003 15:05:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD7Fn-0002mh-00 for disman@ietf.org; Fri, 24 Oct 2003 15:05:43 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AD7Fn-0002m1-00 for disman@ietf.org; Fri, 24 Oct 2003 15:05:43 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9OJ5Bv12469 for ; Fri, 24 Oct 2003 15:05:11 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Oct 2003 15:05:10 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD340905DE64@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: Fri, 24 Oct 2003 15:05:03 -0400 Hi 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. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 23, 2003 2:01 PM To: Disman (E-mail) Subject: Re: [Disman] ituAlarmGenericModel is redundant? Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Wednesday, October 22, 2003 6:57 AM > Subject: RE: [Disman] ituAlarmGenericModel is redundant? ... > It's a useful object. The working felt it was a useful object. I think > it's a useful object. We've never claimed that there wasn't another > means to get this mapping. Why are we suddenly deciding we don't want > this object? ... Redundant objects have long been discouraged. If you believe that there is overwhelming support to retain it, then I suggest we follow Bert's advice from the Mreview mailing list: | In general I discuourage people to create redundant MIB objects. But | ... if they have good reasons, I think we should try to understand | them and make them document it in the MIB documents, preferebaly in | the "duplicate" object DESCRIPTION clause. Randy From exim@www1.ietf.org Fri Oct 24 15:06: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 PAA23793 for ; Fri, 24 Oct 2003 15:06:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7G8-0002ZQ-TZ for disman-archive@odin.ietf.org; Fri, 24 Oct 2003 15:06:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OJ64ha009879 for disman-archive@odin.ietf.org; Fri, 24 Oct 2003 15:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7G8-0002ZG-Qn for disman-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 15:06:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23705 for ; Fri, 24 Oct 2003 15:05:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD7G5-0002n6-00 for disman-web-archive@ietf.org; Fri, 24 Oct 2003 15:06:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD7G4-0002n0-00 for disman-web-archive@ietf.org; Fri, 24 Oct 2003 15:06:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7G5-0002YB-1u; Fri, 24 Oct 2003 15:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7Fr-0002Um-0q for disman@optimus.ietf.org; Fri, 24 Oct 2003 15:05:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23662 for ; Fri, 24 Oct 2003 15:05:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD7Fn-0002mh-00 for disman@ietf.org; Fri, 24 Oct 2003 15:05:43 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AD7Fn-0002m1-00 for disman@ietf.org; Fri, 24 Oct 2003 15:05:43 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9OJ5Bv12469 for ; Fri, 24 Oct 2003 15:05:11 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Oct 2003 15:05:10 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD340905DE64@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: Fri, 24 Oct 2003 15:05:03 -0400 Hi 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. Sharon -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, October 23, 2003 2:01 PM To: Disman (E-mail) Subject: Re: [Disman] ituAlarmGenericModel is redundant? Hi - > From: "Sharon Chisholm" > To: "Disman (E-mail)" > Sent: Wednesday, October 22, 2003 6:57 AM > Subject: RE: [Disman] ituAlarmGenericModel is redundant? ... > It's a useful object. The working felt it was a useful object. I think > it's a useful object. We've never claimed that there wasn't another > means to get this mapping. Why are we suddenly deciding we don't want > this object? ... Redundant objects have long been discouraged. If you believe that there is overwhelming support to retain it, then I suggest we follow Bert's advice from the Mreview mailing list: | In general I discuourage people to create redundant MIB objects. But | ... if they have good reasons, I think we should try to understand | them and make them document it in the MIB documents, preferebaly in | the "duplicate" object DESCRIPTION clause. Randy From disman-admin@ietf.org Fri Oct 24 18:48: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 SAA04617 for ; Fri, 24 Oct 2003 18:48:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADAiu-0004Yx-R0; Fri, 24 Oct 2003 18:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADAiY-0004Wm-QM for disman@optimus.ietf.org; Fri, 24 Oct 2003 18:47:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04572 for ; Fri, 24 Oct 2003 18:47:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADAiV-0005l1-00 for disman@ietf.org; Fri, 24 Oct 2003 18:47:35 -0400 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1ADAiV-0005ky-00 for disman@ietf.org; Fri, 24 Oct 2003 18:47:35 -0400 Received: from h-69-3-242-201.snvacaid.dynamic.covad.net ([69.3.242.201] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ADAiQ-0004gt-00; Fri, 24 Oct 2003 15:47:30 -0700 Message-ID: <001401c39a80$eabf41c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Sharon Chisholm" , "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD340905DE64@zcard0ka.ca.nortel.com> Subject: Re: [Disman] ituAlarmGenericModel is redundant? 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, 24 Oct 2003 15:48:17 -0700 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 Fri Oct 24 18:48: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 SAA04632 for ; Fri, 24 Oct 2003 18:48:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADAix-0004a2-7G for disman-archive@odin.ietf.org; Fri, 24 Oct 2003 18:48:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OMm3oB017600 for disman-archive@odin.ietf.org; Fri, 24 Oct 2003 18:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADAiw-0004Zn-Vk for disman-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 18:48:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04576 for ; Fri, 24 Oct 2003 18:47:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADAit-0005lC-00 for disman-web-archive@ietf.org; Fri, 24 Oct 2003 18:47:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADAit-0005l9-00 for disman-web-archive@ietf.org; Fri, 24 Oct 2003 18:47:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADAiu-0004Yx-R0; Fri, 24 Oct 2003 18:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADAiY-0004Wm-QM for disman@optimus.ietf.org; Fri, 24 Oct 2003 18:47:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04572 for ; Fri, 24 Oct 2003 18:47:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADAiV-0005l1-00 for disman@ietf.org; Fri, 24 Oct 2003 18:47:35 -0400 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1ADAiV-0005ky-00 for disman@ietf.org; Fri, 24 Oct 2003 18:47:35 -0400 Received: from h-69-3-242-201.snvacaid.dynamic.covad.net ([69.3.242.201] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ADAiQ-0004gt-00; Fri, 24 Oct 2003 15:47:30 -0700 Message-ID: <001401c39a80$eabf41c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Sharon Chisholm" , "Disman \(E-mail\)" References: <3549C09B853DD5119B540002A52CDD340905DE64@zcard0ka.ca.nortel.com> Subject: Re: [Disman] ituAlarmGenericModel is redundant? 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, 24 Oct 2003 15:48:17 -0700 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