From entmib-admin@ietf.org Thu Nov 20 12:34:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14857 for ; Thu, 20 Nov 2003 12:34:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsgr-0002bP-8g; Thu, 20 Nov 2003 12:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsgY-0002as-W0 for entmib@optimus.ietf.org; Thu, 20 Nov 2003 12:33:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14844 for ; Thu, 20 Nov 2003 12:33:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMsgX-0006na-00 for entmib@ietf.org; Thu, 20 Nov 2003 12:33:41 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AMsgW-0006nF-00 for entmib@ietf.org; Thu, 20 Nov 2003 12:33:40 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAKHX5D04101 for ; Thu, 20 Nov 2003 12:33:06 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 12:33:06 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954D895@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 20 Nov 2003 12:33:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Entmib] FW: [psg.com #71] AutoReply: entStateAdmin usage clarification re quired Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Sorry for taking so long. I've just submitted an update to that other MIB of mine, so I've got some bandwidth to work on this again. If you remember, we are experimenting with using the problem tracking tool. I'm going to update each problem ticket with the proposed resolution and send it to the mailing list for comment. After some arbitrary amount of time has past, if there are no objections to the proposed resolutions, I'll close the issue in the problem tracker and include the change in the list of changes for the next release of the draft. If there are comments, I'll try to capture that as well in the tracker tool. Sound reasonable? Ok, here goes ... Proposed Resolution for ent-state-71: In the description of entStateAdmin replace "The administrative state for this entity." With "The administrative state for this entity. This object can not be administratively set to 'notSupported'. For entities that do not support administrative state, changing the value of this object to something other than 'notSupported' is not permitted. A value of 'inconsistentValue' will be returned in either case. Some physical entities exhibit only a subset of the remaining administrative state values. Some entities cannot be locked, and hence this object exhibits only the unlocked state. Other entities can not be shut down gracefully, and hence this object does not exhibit the shutting down state. A value of 'inconsistentValue' will be returned if attempts are made to set this object to values not supported by its administrative model." -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Monday, July 14, 2003 12:39 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #71] AutoReply: entStateAdmin usage clarification required ------------------------------------------------------------------------- >From Romascanu, Dan (Dan) [dromasca@avaya.com] "If entStateAdmin is to be made a read-write object, there is a need for more clarity about what values are allowed to be set on write operations. I assume that 'notSupported' is not a writeable value. but how is a physical entity shut down? by setting the value of entStateAdmin to 'shuttingDown' or to 'locked'?" _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Nov 20 12:58:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15899 for ; Thu, 20 Nov 2003 12:58:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMt46-0004cs-LA for entmib-archive@odin.ietf.org; Thu, 20 Nov 2003 12:58:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKHw2pR017778 for entmib-archive@odin.ietf.org; Thu, 20 Nov 2003 12:58:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMt44-0004cW-Sc; Thu, 20 Nov 2003 12:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMt3A-0004bM-Ip for entmib@optimus.ietf.org; Thu, 20 Nov 2003 12:57:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15771 for ; Thu, 20 Nov 2003 12:56:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMt38-00079k-00 for entmib@ietf.org; Thu, 20 Nov 2003 12:57:02 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AMt38-00076m-00 for entmib@ietf.org; Thu, 20 Nov 2003 12:57:02 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAKHtKJ03888 for ; Thu, 20 Nov 2003 12:55:21 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 12:55:21 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954D8C8@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 20 Nov 2003 12:55:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Entmib] FW: [psg.com #72] AutoReply: Usage State: distinction between 'ac tive' and 'busy' Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Proposed Resolution ent-state-72: In the description of entStateUsage replace "The usage state for this entity." With "The usage state for this entity. Note that in the context of a physical entity, this object refers to an entity's ability to service more physical entities in a containment hierarchy. A value of idle means that no other entity is contained within this entity, as would have been demonstrated by a value of entPhysicalContainedIn that referenced this entity. A value of 'active' means that at least one entity is contained within this entity and therefore has a value of entPhysicalContainedIn that references this entity, but that it could handle more. A value of 'busy' means that the entity is unable to handle any additional entities being contained in it, as demonstrated by having a value of entPhysicalContainedIn that refers to this entity." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Monday, July 14, 2003 12:43 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #72] AutoReply: Usage State: distinction between 'active' and 'busy' ------------------------------------------------------------------------- Romascanu, Dan (Dan) [dromasca@avaya.com] "I perceive a problem with the way 'usage state' is being defined and modeled. The distinction between 'active' and 'busy' is not clear. The difference between the two should be whether the entity has spare capacity to serve additional 'users'. A phrase in section 2 mentions that 'In the context of this MIB, the user is equivalent to an entity', and I do not really know how to interpret this. Can entStateUsage of an entity of type powerSupply have a value of 'active' if it does not provide all amperage it is capable of, or only 'busy' is acceptable, as 2.3.4.3 seems to indicate? Same question for a fan, that supports several speeds? " _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Nov 20 13:23:05 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14858 for ; Thu, 20 Nov 2003 12:34:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsgr-0002bb-Jx for entmib-archive@odin.ietf.org; Thu, 20 Nov 2003 12:34:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKHY19g010014 for entmib-archive@odin.ietf.org; Thu, 20 Nov 2003 12:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsgr-0002bP-8g; Thu, 20 Nov 2003 12:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsgY-0002as-W0 for entmib@optimus.ietf.org; Thu, 20 Nov 2003 12:33:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14844 for ; Thu, 20 Nov 2003 12:33:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMsgX-0006na-00 for entmib@ietf.org; Thu, 20 Nov 2003 12:33:41 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AMsgW-0006nF-00 for entmib@ietf.org; Thu, 20 Nov 2003 12:33:40 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAKHX5D04101 for ; Thu, 20 Nov 2003 12:33:06 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 12:33:06 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954D895@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 20 Nov 2003 12:33:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Entmib] FW: [psg.com #71] AutoReply: entStateAdmin usage clarification re quired Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Sorry for taking so long. I've just submitted an update to that other MIB of mine, so I've got some bandwidth to work on this again. If you remember, we are experimenting with using the problem tracking tool. I'm going to update each problem ticket with the proposed resolution and send it to the mailing list for comment. After some arbitrary amount of time has past, if there are no objections to the proposed resolutions, I'll close the issue in the problem tracker and include the change in the list of changes for the next release of the draft. If there are comments, I'll try to capture that as well in the tracker tool. Sound reasonable? Ok, here goes ... Proposed Resolution for ent-state-71: In the description of entStateAdmin replace "The administrative state for this entity." With "The administrative state for this entity. This object can not be administratively set to 'notSupported'. For entities that do not support administrative state, changing the value of this object to something other than 'notSupported' is not permitted. A value of 'inconsistentValue' will be returned in either case. Some physical entities exhibit only a subset of the remaining administrative state values. Some entities cannot be locked, and hence this object exhibits only the unlocked state. Other entities can not be shut down gracefully, and hence this object does not exhibit the shutting down state. A value of 'inconsistentValue' will be returned if attempts are made to set this object to values not supported by its administrative model." -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Monday, July 14, 2003 12:39 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #71] AutoReply: entStateAdmin usage clarification required ------------------------------------------------------------------------- >From Romascanu, Dan (Dan) [dromasca@avaya.com] "If entStateAdmin is to be made a read-write object, there is a need for more clarity about what values are allowed to be set on write operations. I assume that 'notSupported' is not a writeable value. but how is a physical entity shut down? by setting the value of entStateAdmin to 'shuttingDown' or to 'locked'?" _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Thu Nov 20 13:48:07 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15898 for ; Thu, 20 Nov 2003 12:58:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMt44-0004cW-Sc; Thu, 20 Nov 2003 12:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMt3A-0004bM-Ip for entmib@optimus.ietf.org; Thu, 20 Nov 2003 12:57:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15771 for ; Thu, 20 Nov 2003 12:56:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMt38-00079k-00 for entmib@ietf.org; Thu, 20 Nov 2003 12:57:02 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AMt38-00076m-00 for entmib@ietf.org; Thu, 20 Nov 2003 12:57:02 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAKHtKJ03888 for ; Thu, 20 Nov 2003 12:55:21 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 12:55:21 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954D8C8@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 20 Nov 2003 12:55:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Entmib] FW: [psg.com #72] AutoReply: Usage State: distinction between 'ac tive' and 'busy' Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Proposed Resolution ent-state-72: In the description of entStateUsage replace "The usage state for this entity." With "The usage state for this entity. Note that in the context of a physical entity, this object refers to an entity's ability to service more physical entities in a containment hierarchy. A value of idle means that no other entity is contained within this entity, as would have been demonstrated by a value of entPhysicalContainedIn that referenced this entity. A value of 'active' means that at least one entity is contained within this entity and therefore has a value of entPhysicalContainedIn that references this entity, but that it could handle more. A value of 'busy' means that the entity is unable to handle any additional entities being contained in it, as demonstrated by having a value of entPhysicalContainedIn that refers to this entity." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Monday, July 14, 2003 12:43 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #72] AutoReply: Usage State: distinction between 'active' and 'busy' ------------------------------------------------------------------------- Romascanu, Dan (Dan) [dromasca@avaya.com] "I perceive a problem with the way 'usage state' is being defined and modeled. The distinction between 'active' and 'busy' is not clear. The difference between the two should be whether the entity has spare capacity to serve additional 'users'. A phrase in section 2 mentions that 'In the context of this MIB, the user is equivalent to an entity', and I do not really know how to interpret this. Can entStateUsage of an entity of type powerSupply have a value of 'active' if it does not provide all amperage it is capable of, or only 'busy' is acceptable, as 2.3.4.3 seems to indicate? Same question for a fan, that supports several speeds? " _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Nov 21 08:00:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12274 for ; Fri, 21 Nov 2003 08:00:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANAtH-0004p9-Q2; Fri, 21 Nov 2003 08:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANAsi-0004oM-H7 for entmib@optimus.ietf.org; Fri, 21 Nov 2003 07:59:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12252 for ; Fri, 21 Nov 2003 07:59:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANAsh-0001qy-00 for entmib@ietf.org; Fri, 21 Nov 2003 07:59:27 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ANAsh-0001qT-00 for entmib@ietf.org; Fri, 21 Nov 2003 07:59:27 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hALCwtw06759 for ; Fri, 21 Nov 2003 07:58:55 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Nov 2003 07:58:55 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954DD52@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 21 Nov 2003 07:58:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Entmib] FW: [psg.com #73] AutoReply: AlatrmStatusTC - notSupported versus indeterminate Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Proposed Resolution for ent-state-73: In the description of entStateAlarm replace" "The alarm status for this entity. It does not include the severity of alarms raised on child components." With "The alarm status for this entity. It does not include the severity of alarms raised on child components. A value of 'notSupported' means the entity does not support the alarm status object. Note that this differs from 'indeterminate' which means that that alarm state is supported and there are alarms against this entity, but the severity of some of the alarms is not known." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Monday, July 14, 2003 12:58 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #73] AutoReply: AlatrmStatusTC - notSupported versus indeterminate ------------------------------------------------------------------------- Romascanu, Dan (Dan) [dromasca@avaya.com] "A3) AlarmStatusTC - what does setting notSupported(0) bit mean? Is not this same as indeterminate(7)?" _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Nov 21 08:00:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12276 for ; Fri, 21 Nov 2003 08:00:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANAtK-0004px-BQ for entmib-archive@odin.ietf.org; Fri, 21 Nov 2003 08:00:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALD06Nq018558 for entmib-archive@odin.ietf.org; Fri, 21 Nov 2003 08:00:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANAtH-0004p9-Q2; Fri, 21 Nov 2003 08:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANAsi-0004oM-H7 for entmib@optimus.ietf.org; Fri, 21 Nov 2003 07:59:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12252 for ; Fri, 21 Nov 2003 07:59:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANAsh-0001qy-00 for entmib@ietf.org; Fri, 21 Nov 2003 07:59:27 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ANAsh-0001qT-00 for entmib@ietf.org; Fri, 21 Nov 2003 07:59:27 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hALCwtw06759 for ; Fri, 21 Nov 2003 07:58:55 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Nov 2003 07:58:55 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954DD52@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 21 Nov 2003 07:58:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Entmib] FW: [psg.com #73] AutoReply: AlatrmStatusTC - notSupported versus indeterminate Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Proposed Resolution for ent-state-73: In the description of entStateAlarm replace" "The alarm status for this entity. It does not include the severity of alarms raised on child components." With "The alarm status for this entity. It does not include the severity of alarms raised on child components. A value of 'notSupported' means the entity does not support the alarm status object. Note that this differs from 'indeterminate' which means that that alarm state is supported and there are alarms against this entity, but the severity of some of the alarms is not known." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Monday, July 14, 2003 12:58 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #73] AutoReply: AlatrmStatusTC - notSupported versus indeterminate ------------------------------------------------------------------------- Romascanu, Dan (Dan) [dromasca@avaya.com] "A3) AlarmStatusTC - what does setting notSupported(0) bit mean? Is not this same as indeterminate(7)?" _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Nov 21 08:10:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12565 for ; Fri, 21 Nov 2003 08:10:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANB2v-0005UY-AF; Fri, 21 Nov 2003 08:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANB2K-0005TO-Nn for entmib@optimus.ietf.org; Fri, 21 Nov 2003 08:09:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12551 for ; Fri, 21 Nov 2003 08:09:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANB2J-0001zy-00 for entmib@ietf.org; Fri, 21 Nov 2003 08:09:23 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ANB2I-0001zp-00 for entmib@ietf.org; Fri, 21 Nov 2003 08:09:23 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hALD8oD23690 for ; Fri, 21 Nov 2003 08:08:50 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Nov 2003 08:08:50 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954DD62@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 21 Nov 2003 08:08:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Entmib] FW: [psg.com #74] AutoReply: StandbyStatus TC - a new value for l oad-sharing Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Proposed Resolution for ent-state-74: While we are certainly open to modifying the state model as appropriate, given the current definition of the StandyByStatus: SYNTAX INTEGER { notSupported (1), hotStandby(2), coldStandby(3), providingService(4) } It seems that 'loadSharing' would be more of a specialization of 'providingSerice' than a peer concept. I propose not including it in this list. The question of adding another object to provide this sort of information was briefly discussed in the Vienna meeting and it was felt that our intention was to not provide a full set of objects to support redundancy. I propose we do not add this object at this time. Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, July 15, 2003 3:53 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #74] AutoReply: StandbyStatus TC - a new value for load-sharing ------------------------------------------------------------------------- Romascanu, Dan (Dan) [dromasca@avaya.com] "StandbyStatus TC - I think that there is a need to define a new value for 'load-sharing', even if this is not defined in X.731" _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Nov 21 08:10:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12567 for ; Fri, 21 Nov 2003 08:10:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANB2w-0005V9-0v for entmib-archive@odin.ietf.org; Fri, 21 Nov 2003 08:10:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALDA1jF021125 for entmib-archive@odin.ietf.org; Fri, 21 Nov 2003 08:10:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANB2v-0005UY-AF; Fri, 21 Nov 2003 08:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANB2K-0005TO-Nn for entmib@optimus.ietf.org; Fri, 21 Nov 2003 08:09:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12551 for ; Fri, 21 Nov 2003 08:09:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANB2J-0001zy-00 for entmib@ietf.org; Fri, 21 Nov 2003 08:09:23 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ANB2I-0001zp-00 for entmib@ietf.org; Fri, 21 Nov 2003 08:09:23 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hALD8oD23690 for ; Fri, 21 Nov 2003 08:08:50 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Nov 2003 08:08:50 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954DD62@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 21 Nov 2003 08:08:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Entmib] FW: [psg.com #74] AutoReply: StandbyStatus TC - a new value for l oad-sharing Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Proposed Resolution for ent-state-74: While we are certainly open to modifying the state model as appropriate, given the current definition of the StandyByStatus: SYNTAX INTEGER { notSupported (1), hotStandby(2), coldStandby(3), providingService(4) } It seems that 'loadSharing' would be more of a specialization of 'providingSerice' than a peer concept. I propose not including it in this list. The question of adding another object to provide this sort of information was briefly discussed in the Vienna meeting and it was felt that our intention was to not provide a full set of objects to support redundancy. I propose we do not add this object at this time. Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, July 15, 2003 3:53 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #74] AutoReply: StandbyStatus TC - a new value for load-sharing ------------------------------------------------------------------------- Romascanu, Dan (Dan) [dromasca@avaya.com] "StandbyStatus TC - I think that there is a need to define a new value for 'load-sharing', even if this is not defined in X.731" _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Nov 21 08:31:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12944 for ; Fri, 21 Nov 2003 08:31:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBNH-0006L6-1B; Fri, 21 Nov 2003 08:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBMh-0006K2-MV for entmib@optimus.ietf.org; Fri, 21 Nov 2003 08:30:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12910 for ; Fri, 21 Nov 2003 08:30:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANBMg-0002Aw-00 for entmib@ietf.org; Fri, 21 Nov 2003 08:30:26 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ANBMf-0002AL-00 for entmib@ietf.org; Fri, 21 Nov 2003 08:30:26 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hALDTsD25710 for ; Fri, 21 Nov 2003 08:29:54 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Nov 2003 08:29:54 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954DD8D@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 21 Nov 2003 08:29:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Entmib] FW: [psg.com #75] AutoReply: Notifications Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Proposed Resolution ent-state-75: Note that the operational state can only take on three values { notSupported (1), disabled(2), enabled(3) } notSupported would mean these notifications would never be sent. A value of disabled means that entStateOperDisabled would be sent. enabled means that entStateOperEnabled would be sent. So, while the notifications can certainly benefit from some clarifying text, actually varbinding in operational state is redundant. If people feel it would be of value to put it in anyways, I'm game, but for now I propose we don't. I'm open to suggestions for the name of the notifications. In the description of entStateOperEnabled replace "The entity is operational. The entity this notification refers can be identified by extracting the entPhysicalIndex from one of the variable bindings." With "An entStateOperEnabled trap signifies that the SNMP entity, acting in an agent role, has detected that the entStateOper object for one of its entitiesleft the disabled state and transitioned into the enabled state. The entity this notification refers can be identified by extracting the entPhysicalIndex from one of the variable bindings." And in the description of entStateOperDisabled replace "The entity is not operational. The entity this notification refers can be identified by extracting the entPhysicalIndex from one of the variable bindings." With "An entStateOperDisabled trap signifies that the SNMP entity, acting in an agent role, has detected that the entStateOper object for one of its entities left the enabled state and transitioned into the disabled state. The entity this notification refers can be identified by extracting the entPhysicalIndex from one of the variable bindings." And in the entStateCompliance and the following GROUP entStateNotificationsGroup DESCRIPTION "This group is optional." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, July 15, 2003 4:12 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #75] AutoReply: Notifications ------------------------------------------------------------------------- Romascanu, Dan (Dan) [dromasca@avaya.com] "Notifications - first the names are very confusing - they are called OperEnabled and OperDisabled, while they carry only entStateAdmin, and entStateAlarm objects. I think that at least entStateOper should be added. It also is not defined when these notifications are supposed to be sent. " Juergen Schoenwaelder [schoenw@ibr.cs.tu-bs.de] 'l) Implementation of the notifications is unconditionally optional? ' _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Nov 21 08:31:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12946 for ; Fri, 21 Nov 2003 08:31:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBNH-0006Lc-C6 for entmib-archive@odin.ietf.org; Fri, 21 Nov 2003 08:31:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALDV3wL024384 for entmib-archive@odin.ietf.org; Fri, 21 Nov 2003 08:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBNH-0006L6-1B; Fri, 21 Nov 2003 08:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBMh-0006K2-MV for entmib@optimus.ietf.org; Fri, 21 Nov 2003 08:30:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12910 for ; Fri, 21 Nov 2003 08:30:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANBMg-0002Aw-00 for entmib@ietf.org; Fri, 21 Nov 2003 08:30:26 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ANBMf-0002AL-00 for entmib@ietf.org; Fri, 21 Nov 2003 08:30:26 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hALDTsD25710 for ; Fri, 21 Nov 2003 08:29:54 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Nov 2003 08:29:54 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954DD8D@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 21 Nov 2003 08:29:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Entmib] FW: [psg.com #75] AutoReply: Notifications Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Proposed Resolution ent-state-75: Note that the operational state can only take on three values { notSupported (1), disabled(2), enabled(3) } notSupported would mean these notifications would never be sent. A value of disabled means that entStateOperDisabled would be sent. enabled means that entStateOperEnabled would be sent. So, while the notifications can certainly benefit from some clarifying text, actually varbinding in operational state is redundant. If people feel it would be of value to put it in anyways, I'm game, but for now I propose we don't. I'm open to suggestions for the name of the notifications. In the description of entStateOperEnabled replace "The entity is operational. The entity this notification refers can be identified by extracting the entPhysicalIndex from one of the variable bindings." With "An entStateOperEnabled trap signifies that the SNMP entity, acting in an agent role, has detected that the entStateOper object for one of its entitiesleft the disabled state and transitioned into the enabled state. The entity this notification refers can be identified by extracting the entPhysicalIndex from one of the variable bindings." And in the description of entStateOperDisabled replace "The entity is not operational. The entity this notification refers can be identified by extracting the entPhysicalIndex from one of the variable bindings." With "An entStateOperDisabled trap signifies that the SNMP entity, acting in an agent role, has detected that the entStateOper object for one of its entities left the enabled state and transitioned into the disabled state. The entity this notification refers can be identified by extracting the entPhysicalIndex from one of the variable bindings." And in the entStateCompliance and the following GROUP entStateNotificationsGroup DESCRIPTION "This group is optional." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, July 15, 2003 4:12 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #75] AutoReply: Notifications ------------------------------------------------------------------------- Romascanu, Dan (Dan) [dromasca@avaya.com] "Notifications - first the names are very confusing - they are called OperEnabled and OperDisabled, while they carry only entStateAdmin, and entStateAlarm objects. I think that at least entStateOper should be added. It also is not defined when these notifications are supposed to be sent. " Juergen Schoenwaelder [schoenw@ibr.cs.tu-bs.de] 'l) Implementation of the notifications is unconditionally optional? ' _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Nov 21 10:21:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17625 for ; Fri, 21 Nov 2003 10:21:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AND5j-0005NC-PL for entmib-archive@odin.ietf.org; Fri, 21 Nov 2003 10:21:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALFL3fg020630 for entmib-archive@odin.ietf.org; Fri, 21 Nov 2003 10:21:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AND5j-0005ME-0f; Fri, 21 Nov 2003 10:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AND5b-0005Je-SC for entmib@optimus.ietf.org; Fri, 21 Nov 2003 10:20:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17536 for ; Fri, 21 Nov 2003 10:20:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AND5U-0003cA-00 for entmib@ietf.org; Fri, 21 Nov 2003 10:20:48 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AND5U-0003bQ-00 for entmib@ietf.org; Fri, 21 Nov 2003 10:20:48 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hALFKGw06100 for ; Fri, 21 Nov 2003 10:20:16 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Nov 2003 10:20:16 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954DF8D@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 21 Nov 2003 10:20:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Entmib] FW: [psg.com #76] AutoReply: Security Considerations Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Proposed Resolution ent-state-76: Add the following to the Security Considerations section: "Note that setting the entStateAdmin to disabled can cause disruption of services ranging from those running on a port or an entire device, depending on the type of entity. Access to this object should be properly protected. Access to the objects defined in this MIB allows one to figure out what the active and standby resources in a network are. This information can be used to optimize attacks on networks so even read-only access to this MIB should be properly protected." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, July 15, 2003 4:21 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #76] AutoReply: Security Considerations ------------------------------------------------------------------------- Romascanu, Dan (Dan) [dromasca@avaya.com] "The Security Considerations section should clearly articulate the operational risks of writing on entStateAdmin." Juergen Schoenwaelder [schoenw@ibr.cs.tu-bs.de] 'm) In the security section, you may want to explain that access to the objects defined in this MIB allows to figure out what the active and standby resources in a network are and that this information can be used to optimize attacks on networks. So even read-only access to this MIB should be properly protected.' _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Nov 21 10:25:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17749 for ; Fri, 21 Nov 2003 10:25:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AND9Z-0005VJ-Qu for entmib-archive@odin.ietf.org; Fri, 21 Nov 2003 10:25:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALFP1Ej021133 for entmib-archive@odin.ietf.org; Fri, 21 Nov 2003 10:25:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AND9Z-0005UO-26; Fri, 21 Nov 2003 10:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AND8u-0005Ta-Gd for entmib@optimus.ietf.org; Fri, 21 Nov 2003 10:24:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17725 for ; Fri, 21 Nov 2003 10:24:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AND8s-0003gM-00 for entmib@ietf.org; Fri, 21 Nov 2003 10:24:18 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AND8r-0003fz-00 for entmib@ietf.org; Fri, 21 Nov 2003 10:24:17 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hALFNkD24827 for ; Fri, 21 Nov 2003 10:23:46 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Nov 2003 10:23:46 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954DFA0@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #76] AutoReply: Security Considerations Date: Fri, 21 Nov 2003 10:23:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Oops. Make that "locked or shuttingDown" instead of disabled for the first one. Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Friday, November 21, 2003 10:20 AM To: entmib@ietf.org Subject: [Entmib] FW: [psg.com #76] AutoReply: Security Considerations Hi Proposed Resolution ent-state-76: Add the following to the Security Considerations section: "Note that setting the entStateAdmin to disabled can cause disruption of services ranging from those running on a port or an entire device, depending on the type of entity. Access to this object should be properly protected. Access to the objects defined in this MIB allows one to figure out what the active and standby resources in a network are. This information can be used to optimize attacks on networks so even read-only access to this MIB should be properly protected." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, July 15, 2003 4:21 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #76] AutoReply: Security Considerations ------------------------------------------------------------------------- Romascanu, Dan (Dan) [dromasca@avaya.com] "The Security Considerations section should clearly articulate the operational risks of writing on entStateAdmin." Juergen Schoenwaelder [schoenw@ibr.cs.tu-bs.de] 'm) In the security section, you may want to explain that access to the objects defined in this MIB allows to figure out what the active and standby resources in a network are and that this information can be used to optimize attacks on networks. So even read-only access to this MIB should be properly protected.' _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Nov 21 11:13:14 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17623 for ; Fri, 21 Nov 2003 10:21:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AND5j-0005ME-0f; Fri, 21 Nov 2003 10:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AND5b-0005Je-SC for entmib@optimus.ietf.org; Fri, 21 Nov 2003 10:20:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17536 for ; Fri, 21 Nov 2003 10:20:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AND5U-0003cA-00 for entmib@ietf.org; Fri, 21 Nov 2003 10:20:48 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AND5U-0003bQ-00 for entmib@ietf.org; Fri, 21 Nov 2003 10:20:48 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hALFKGw06100 for ; Fri, 21 Nov 2003 10:20:16 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Nov 2003 10:20:16 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954DF8D@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 21 Nov 2003 10:20:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Entmib] FW: [psg.com #76] AutoReply: Security Considerations Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Proposed Resolution ent-state-76: Add the following to the Security Considerations section: "Note that setting the entStateAdmin to disabled can cause disruption of services ranging from those running on a port or an entire device, depending on the type of entity. Access to this object should be properly protected. Access to the objects defined in this MIB allows one to figure out what the active and standby resources in a network are. This information can be used to optimize attacks on networks so even read-only access to this MIB should be properly protected." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, July 15, 2003 4:21 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #76] AutoReply: Security Considerations ------------------------------------------------------------------------- Romascanu, Dan (Dan) [dromasca@avaya.com] "The Security Considerations section should clearly articulate the operational risks of writing on entStateAdmin." Juergen Schoenwaelder [schoenw@ibr.cs.tu-bs.de] 'm) In the security section, you may want to explain that access to the objects defined in this MIB allows to figure out what the active and standby resources in a network are and that this information can be used to optimize attacks on networks. So even read-only access to this MIB should be properly protected.' _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Nov 21 11:13:14 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17748 for ; Fri, 21 Nov 2003 10:25:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AND9Z-0005UO-26; Fri, 21 Nov 2003 10:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AND8u-0005Ta-Gd for entmib@optimus.ietf.org; Fri, 21 Nov 2003 10:24:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17725 for ; Fri, 21 Nov 2003 10:24:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AND8s-0003gM-00 for entmib@ietf.org; Fri, 21 Nov 2003 10:24:18 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AND8r-0003fz-00 for entmib@ietf.org; Fri, 21 Nov 2003 10:24:17 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hALFNkD24827 for ; Fri, 21 Nov 2003 10:23:46 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Nov 2003 10:23:46 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954DFA0@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #76] AutoReply: Security Considerations Date: Fri, 21 Nov 2003 10:23:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Oops. Make that "locked or shuttingDown" instead of disabled for the first one. Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Friday, November 21, 2003 10:20 AM To: entmib@ietf.org Subject: [Entmib] FW: [psg.com #76] AutoReply: Security Considerations Hi Proposed Resolution ent-state-76: Add the following to the Security Considerations section: "Note that setting the entStateAdmin to disabled can cause disruption of services ranging from those running on a port or an entire device, depending on the type of entity. Access to this object should be properly protected. Access to the objects defined in this MIB allows one to figure out what the active and standby resources in a network are. This information can be used to optimize attacks on networks so even read-only access to this MIB should be properly protected." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, July 15, 2003 4:21 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #76] AutoReply: Security Considerations ------------------------------------------------------------------------- Romascanu, Dan (Dan) [dromasca@avaya.com] "The Security Considerations section should clearly articulate the operational risks of writing on entStateAdmin." Juergen Schoenwaelder [schoenw@ibr.cs.tu-bs.de] 'm) In the security section, you may want to explain that access to the objects defined in this MIB allows to figure out what the active and standby resources in a network are and that this information can be used to optimize attacks on networks. So even read-only access to this MIB should be properly protected.' _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Nov 21 13:39:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26153 for ; Fri, 21 Nov 2003 13:39:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGBI-0003Md-Ud; Fri, 21 Nov 2003 13:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGAd-0003Ky-5K for entmib@optimus.ietf.org; Fri, 21 Nov 2003 13:38:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26112 for ; Fri, 21 Nov 2003 13:38:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANGAa-0006ok-00 for entmib@ietf.org; Fri, 21 Nov 2003 13:38:16 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ANGAa-0006oY-00 for entmib@ietf.org; Fri, 21 Nov 2003 13:38:16 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hALIbiw16575 for ; Fri, 21 Nov 2003 13:37:45 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Nov 2003 13:37:44 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954E271@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 21 Nov 2003 13:37:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Proposed Resolution to ent-state-77: Actually, I believe what you are describing is in section 2.2.2. I propose that no change is required as a result of this comment. -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, July 15, 2003 4:24 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #77] AutoReply: Operational State Disabled - corrective action required? ------------------------------------------------------------------------- Romascanu, Dan (Dan) [dromasca@avaya.com] "Section 2.2.1 in [in version 01]- A corrective action is not necessary in all cases to make an entity available for use. In some cases setting the admin state to unlock should be enough." _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Nov 21 14:14:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27282 for ; Fri, 21 Nov 2003 14:14:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGjA-0005IQ-Lo; Fri, 21 Nov 2003 14:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGiG-0005HG-GR for entmib@optimus.ietf.org; Fri, 21 Nov 2003 14:13:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27251 for ; Fri, 21 Nov 2003 14:12:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANGiD-0007CQ-00 for entmib@ietf.org; Fri, 21 Nov 2003 14:13:02 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ANGiD-0007CN-00 for entmib@ietf.org; Fri, 21 Nov 2003 14:13:01 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hALJCR2Y017699 for ; Fri, 21 Nov 2003 14:12:27 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hALJCP2Y017665 for ; Fri, 21 Nov 2003 14:12:25 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? Date: Fri, 21 Nov 2003 21:12:58 +0200 Message-ID: Thread-Topic: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? Thread-Index: AcOwXsJMljyO43dWSHe2ORcaGpg9sgABBOFg From: "Romascanu, Dan (Dan)" To: "Sharon Chisholm" , Content-Transfer-Encoding: quoted-printable Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sharon, You are correct about the section number. The text I was commenting on = is in Section 2.2.1 2.2.1 Admin State Locked, Operational State Disabled and Usage State = Idle The entity is totally inoperable, it is not servicing any entities and it is also administratively prohibited from use. To make it available for use, both management permission and some corrective action are necessary. This is similar to an ifAdminStatus of down and ifOperStatus of down. I still believe that there is no need for a corrective action in all = cases. In some cases restoring management permission by setting=20 the admin state to unlock should be enough. The suggested text: The entity is totally inoperable, it is not servicing any entities and it is also administratively prohibited from use. To make it available for use, management permission (and in some cases = corrective action) are necessary. This is similar to an ifAdminStatus of down and ifOperStatus of down. Regards, Dan > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On=20 > Behalf Of Sharon Chisholm > Sent: 21 November, 2003 8:38 PM > To: entmib@ietf.org > Subject: [Entmib] FW: [psg.com #77] AutoReply: Operational=20 > State Disabled - correct ive action required? >=20 >=20 > Hi >=20 > Proposed Resolution to ent-state-77: >=20 > Actually, I believe what you are describing is in section 2.2.2. >=20 > I propose that no change is required as a result of this comment. >=20 >=20 > -----Original Message----- > From: entity-state [mailto:rt+entity-state@rt.psg.com]=20 > Sent: Tuesday, July 15, 2003 4:24 AM > To: Chisholm, Sharon [CAR:0S00:EXCH] > Subject: [psg.com #77] AutoReply: Operational State Disabled=20 > - corrective > action required? >=20 > >=20 > -------------------------------------------------------------- > ----------- > Romascanu, Dan (Dan) [dromasca@avaya.com] >=20 > "Section 2.2.1 in [in version 01]- A corrective action is not=20 > necessary=20 > in all cases to make an entity available for use. In some=20 > cases setting=20 > the admin state to unlock should be enough." >=20 > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib >=20 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Nov 21 14:14:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27293 for ; Fri, 21 Nov 2003 14:14:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGjB-0005JJ-2U for entmib-archive@odin.ietf.org; Fri, 21 Nov 2003 14:14:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALJE1lc020377 for entmib-archive@odin.ietf.org; Fri, 21 Nov 2003 14:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGjA-0005IQ-Lo; Fri, 21 Nov 2003 14:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGiG-0005HG-GR for entmib@optimus.ietf.org; Fri, 21 Nov 2003 14:13:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27251 for ; Fri, 21 Nov 2003 14:12:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANGiD-0007CQ-00 for entmib@ietf.org; Fri, 21 Nov 2003 14:13:02 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ANGiD-0007CN-00 for entmib@ietf.org; Fri, 21 Nov 2003 14:13:01 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hALJCR2Y017699 for ; Fri, 21 Nov 2003 14:12:27 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hALJCP2Y017665 for ; Fri, 21 Nov 2003 14:12:25 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? Date: Fri, 21 Nov 2003 21:12:58 +0200 Message-ID: Thread-Topic: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? Thread-Index: AcOwXsJMljyO43dWSHe2ORcaGpg9sgABBOFg From: "Romascanu, Dan (Dan)" To: "Sharon Chisholm" , Content-Transfer-Encoding: quoted-printable Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sharon, You are correct about the section number. The text I was commenting on = is in Section 2.2.1 2.2.1 Admin State Locked, Operational State Disabled and Usage State = Idle The entity is totally inoperable, it is not servicing any entities and it is also administratively prohibited from use. To make it available for use, both management permission and some corrective action are necessary. This is similar to an ifAdminStatus of down and ifOperStatus of down. I still believe that there is no need for a corrective action in all = cases. In some cases restoring management permission by setting=20 the admin state to unlock should be enough. The suggested text: The entity is totally inoperable, it is not servicing any entities and it is also administratively prohibited from use. To make it available for use, management permission (and in some cases = corrective action) are necessary. This is similar to an ifAdminStatus of down and ifOperStatus of down. Regards, Dan > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On=20 > Behalf Of Sharon Chisholm > Sent: 21 November, 2003 8:38 PM > To: entmib@ietf.org > Subject: [Entmib] FW: [psg.com #77] AutoReply: Operational=20 > State Disabled - correct ive action required? >=20 >=20 > Hi >=20 > Proposed Resolution to ent-state-77: >=20 > Actually, I believe what you are describing is in section 2.2.2. >=20 > I propose that no change is required as a result of this comment. >=20 >=20 > -----Original Message----- > From: entity-state [mailto:rt+entity-state@rt.psg.com]=20 > Sent: Tuesday, July 15, 2003 4:24 AM > To: Chisholm, Sharon [CAR:0S00:EXCH] > Subject: [psg.com #77] AutoReply: Operational State Disabled=20 > - corrective > action required? >=20 > >=20 > -------------------------------------------------------------- > ----------- > Romascanu, Dan (Dan) [dromasca@avaya.com] >=20 > "Section 2.2.1 in [in version 01]- A corrective action is not=20 > necessary=20 > in all cases to make an entity available for use. In some=20 > cases setting=20 > the admin state to unlock should be enough." >=20 > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib >=20 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Nov 21 14:28:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26155 for ; Fri, 21 Nov 2003 13:39:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGBJ-0003N7-Ca for entmib-archive@odin.ietf.org; Fri, 21 Nov 2003 13:39:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALId1CN012945 for entmib-archive@odin.ietf.org; Fri, 21 Nov 2003 13:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGBI-0003Md-Ud; Fri, 21 Nov 2003 13:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGAd-0003Ky-5K for entmib@optimus.ietf.org; Fri, 21 Nov 2003 13:38:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26112 for ; Fri, 21 Nov 2003 13:38:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANGAa-0006ok-00 for entmib@ietf.org; Fri, 21 Nov 2003 13:38:16 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ANGAa-0006oY-00 for entmib@ietf.org; Fri, 21 Nov 2003 13:38:16 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hALIbiw16575 for ; Fri, 21 Nov 2003 13:37:45 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Nov 2003 13:37:44 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954E271@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 21 Nov 2003 13:37:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Proposed Resolution to ent-state-77: Actually, I believe what you are describing is in section 2.2.2. I propose that no change is required as a result of this comment. -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, July 15, 2003 4:24 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #77] AutoReply: Operational State Disabled - corrective action required? ------------------------------------------------------------------------- Romascanu, Dan (Dan) [dromasca@avaya.com] "Section 2.2.1 in [in version 01]- A corrective action is not necessary in all cases to make an entity available for use. In some cases setting the admin state to unlock should be enough." _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Nov 21 14:37:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28200 for ; Fri, 21 Nov 2003 14:37:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANH5Q-0006ux-6o; Fri, 21 Nov 2003 14:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANH4U-0006qW-8x for entmib@optimus.ietf.org; Fri, 21 Nov 2003 14:36:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28077 for ; Fri, 21 Nov 2003 14:35:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANH4R-0007WS-00 for entmib@ietf.org; Fri, 21 Nov 2003 14:35:59 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ANH4R-0007WH-00 for entmib@ietf.org; Fri, 21 Nov 2003 14:35:59 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hALJZRw28534 for ; Fri, 21 Nov 2003 14:35:28 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Nov 2003 14:35:27 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954E34A@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disab led - correct ive action required? Date: Fri, 21 Nov 2003 14:35:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Well, the difference between 2.2.1 and 2.2.2 is that one can be made operational simply by enabling the administrative state while one requires some corrective action AND someone to enable the administrative state. I think this covers all the cases you are referring to. Or am I missing something? Sharon -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Friday, November 21, 2003 2:13 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? Sharon, You are correct about the section number. The text I was commenting on is in Section 2.2.1 2.2.1 Admin State Locked, Operational State Disabled and Usage State Idle The entity is totally inoperable, it is not servicing any entities and it is also administratively prohibited from use. To make it available for use, both management permission and some corrective action are necessary. This is similar to an ifAdminStatus of down and ifOperStatus of down. I still believe that there is no need for a corrective action in all cases. In some cases restoring management permission by setting the admin state to unlock should be enough. The suggested text: The entity is totally inoperable, it is not servicing any entities and it is also administratively prohibited from use. To make it available for use, management permission (and in some cases corrective action) are necessary. This is similar to an ifAdminStatus of down and ifOperStatus of down. Regards, Dan > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On > Behalf Of Sharon Chisholm > Sent: 21 November, 2003 8:38 PM > To: entmib@ietf.org > Subject: [Entmib] FW: [psg.com #77] AutoReply: Operational > State Disabled - correct ive action required? > > > Hi > > Proposed Resolution to ent-state-77: > > Actually, I believe what you are describing is in section 2.2.2. > > I propose that no change is required as a result of this comment. > > > -----Original Message----- > From: entity-state [mailto:rt+entity-state@rt.psg.com] > Sent: Tuesday, July 15, 2003 4:24 AM > To: Chisholm, Sharon [CAR:0S00:EXCH] > Subject: [psg.com #77] AutoReply: Operational State Disabled > - corrective > action required? > > > > -------------------------------------------------------------- > ----------- > Romascanu, Dan (Dan) [dromasca@avaya.com] > > "Section 2.2.1 in [in version 01]- A corrective action is not > necessary > in all cases to make an entity available for use. In some > cases setting > the admin state to unlock should be enough." > > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib > _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Nov 21 14:37:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28215 for ; Fri, 21 Nov 2003 14:37:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANH5R-0006w8-Ax for entmib-archive@odin.ietf.org; Fri, 21 Nov 2003 14:37:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALJb0pJ026609 for entmib-archive@odin.ietf.org; Fri, 21 Nov 2003 14:37:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANH5Q-0006ux-6o; Fri, 21 Nov 2003 14:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANH4U-0006qW-8x for entmib@optimus.ietf.org; Fri, 21 Nov 2003 14:36:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28077 for ; Fri, 21 Nov 2003 14:35:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANH4R-0007WS-00 for entmib@ietf.org; Fri, 21 Nov 2003 14:35:59 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ANH4R-0007WH-00 for entmib@ietf.org; Fri, 21 Nov 2003 14:35:59 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hALJZRw28534 for ; Fri, 21 Nov 2003 14:35:28 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Nov 2003 14:35:27 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954E34A@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disab led - correct ive action required? Date: Fri, 21 Nov 2003 14:35:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Well, the difference between 2.2.1 and 2.2.2 is that one can be made operational simply by enabling the administrative state while one requires some corrective action AND someone to enable the administrative state. I think this covers all the cases you are referring to. Or am I missing something? Sharon -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Friday, November 21, 2003 2:13 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? Sharon, You are correct about the section number. The text I was commenting on is in Section 2.2.1 2.2.1 Admin State Locked, Operational State Disabled and Usage State Idle The entity is totally inoperable, it is not servicing any entities and it is also administratively prohibited from use. To make it available for use, both management permission and some corrective action are necessary. This is similar to an ifAdminStatus of down and ifOperStatus of down. I still believe that there is no need for a corrective action in all cases. In some cases restoring management permission by setting the admin state to unlock should be enough. The suggested text: The entity is totally inoperable, it is not servicing any entities and it is also administratively prohibited from use. To make it available for use, management permission (and in some cases corrective action) are necessary. This is similar to an ifAdminStatus of down and ifOperStatus of down. Regards, Dan > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On > Behalf Of Sharon Chisholm > Sent: 21 November, 2003 8:38 PM > To: entmib@ietf.org > Subject: [Entmib] FW: [psg.com #77] AutoReply: Operational > State Disabled - correct ive action required? > > > Hi > > Proposed Resolution to ent-state-77: > > Actually, I believe what you are describing is in section 2.2.2. > > I propose that no change is required as a result of this comment. > > > -----Original Message----- > From: entity-state [mailto:rt+entity-state@rt.psg.com] > Sent: Tuesday, July 15, 2003 4:24 AM > To: Chisholm, Sharon [CAR:0S00:EXCH] > Subject: [psg.com #77] AutoReply: Operational State Disabled > - corrective > action required? > > > > -------------------------------------------------------------- > ----------- > Romascanu, Dan (Dan) [dromasca@avaya.com] > > "Section 2.2.1 in [in version 01]- A corrective action is not > necessary > in all cases to make an entity available for use. In some > cases setting > the admin state to unlock should be enough." > > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib > _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Nov 21 14:54:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28614 for ; Fri, 21 Nov 2003 14:54:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANHLs-0008Ak-NB; Fri, 21 Nov 2003 14:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANHL8-00089y-1f for entmib@optimus.ietf.org; Fri, 21 Nov 2003 14:53:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28586 for ; Fri, 21 Nov 2003 14:53:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANHL5-0007gd-00 for entmib@ietf.org; Fri, 21 Nov 2003 14:53:11 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1ANHL4-0007ga-00 for entmib@ietf.org; Fri, 21 Nov 2003 14:53:10 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hALJoc5C007514 for ; Fri, 21 Nov 2003 14:50:38 -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 hALJoZ5C007355 for ; Fri, 21 Nov 2003 14:50:36 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? Date: Fri, 21 Nov 2003 21:53:05 +0200 Message-ID: Thread-Topic: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? Thread-Index: AcOwZtkoxG2KVZxCSZOQCdlhgCId8wAAYfWQ From: "Romascanu, Dan (Dan)" To: "Sharon Chisholm" , Content-Transfer-Encoding: quoted-printable Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable 2.2.2 is fine. It looks to me that what is not covered in the current version of 2.2.1 = is the case of these devices that are modeled in their state machine so = that the operStatus follows a adminStatus transition to down, although = no fault was detected on the respective interface. These interfaces will = never be in the state described by 2.2.2. For these cases, when = adminStatus transitions back to up is enough to re-establish operStatus = as well.=20 (I used the IETF MIB-II terminology that I am more familiar with) Regards, Dan > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On=20 > Behalf Of Sharon Chisholm > Sent: 21 November, 2003 9:35 PM > To: entmib@ietf.org > Subject: RE: [Entmib] FW: [psg.com #77] AutoReply:=20 > Operational State Disabled - correct ive action required? >=20 >=20 > Hi >=20 > Well, the difference between 2.2.1 and 2.2.2 is that one can be made > operational simply by enabling the administrative state while=20 > one requires > some corrective action AND someone to enable the=20 > administrative state. I > think this covers all the cases you are referring to. Or am I missing > something? >=20 > Sharon >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: Friday, November 21, 2003 2:13 PM > To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org > Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: Operational State > Disabled - correct ive action required? >=20 >=20 > Sharon, >=20 > You are correct about the section number. The text I was=20 > commenting on is in > Section 2.2.1 >=20 > 2.2.1 Admin State Locked, Operational State Disabled and=20 > Usage State Idle >=20 > The entity is totally inoperable, it is not servicing any entities > and it is also administratively prohibited from use. To make it > available for use, both management permission and some corrective > action are necessary. This is similar to an ifAdminStatus of down > and ifOperStatus of down. >=20 > I still believe that there is no need for a corrective action=20 > in all cases. > In some cases restoring management permission by setting=20 > the admin state to unlock should be enough. The suggested text: >=20 > The entity is totally inoperable, it is not servicing any entities > and it is also administratively prohibited from use. To make it > available for use, management permission (and in some=20 > cases corrective > action) are necessary. This is similar to an ifAdminStatus of down > and ifOperStatus of down. >=20 > Regards, >=20 > Dan >=20 >=20 >=20 > > -----Original Message----- > > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On > > Behalf Of Sharon Chisholm > > Sent: 21 November, 2003 8:38 PM > > To: entmib@ietf.org > > Subject: [Entmib] FW: [psg.com #77] AutoReply: Operational=20 > > State Disabled - correct ive action required? > >=20 > >=20 > > Hi > >=20 > > Proposed Resolution to ent-state-77: > >=20 > > Actually, I believe what you are describing is in section 2.2.2. > >=20 > > I propose that no change is required as a result of this comment. > >=20 > >=20 > > -----Original Message----- > > From: entity-state [mailto:rt+entity-state@rt.psg.com] > > Sent: Tuesday, July 15, 2003 4:24 AM > > To: Chisholm, Sharon [CAR:0S00:EXCH] > > Subject: [psg.com #77] AutoReply: Operational State Disabled=20 > > - corrective > > action required? > >=20 > > > >=20 > > -------------------------------------------------------------- > > ----------- > > Romascanu, Dan (Dan) [dromasca@avaya.com] > >=20 > > "Section 2.2.1 in [in version 01]- A corrective action is not > > necessary=20 > > in all cases to make an entity available for use. In some=20 > > cases setting=20 > > the admin state to unlock should be enough." > >=20 > > _______________________________________________ > > Entmib mailing list > > Entmib@ietf.org > > https://www1.ietf.org/mailman/listinfo/entmib > >=20 >=20 > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib >=20 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Nov 21 14:54:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28625 for ; Fri, 21 Nov 2003 14:54:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANHLt-0008BK-Ay for entmib-archive@odin.ietf.org; Fri, 21 Nov 2003 14:54:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALJs12c031433 for entmib-archive@odin.ietf.org; Fri, 21 Nov 2003 14:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANHLs-0008Ak-NB; Fri, 21 Nov 2003 14:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANHL8-00089y-1f for entmib@optimus.ietf.org; Fri, 21 Nov 2003 14:53:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28586 for ; Fri, 21 Nov 2003 14:53:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANHL5-0007gd-00 for entmib@ietf.org; Fri, 21 Nov 2003 14:53:11 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1ANHL4-0007ga-00 for entmib@ietf.org; Fri, 21 Nov 2003 14:53:10 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hALJoc5C007514 for ; Fri, 21 Nov 2003 14:50:38 -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 hALJoZ5C007355 for ; Fri, 21 Nov 2003 14:50:36 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? Date: Fri, 21 Nov 2003 21:53:05 +0200 Message-ID: Thread-Topic: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? Thread-Index: AcOwZtkoxG2KVZxCSZOQCdlhgCId8wAAYfWQ From: "Romascanu, Dan (Dan)" To: "Sharon Chisholm" , Content-Transfer-Encoding: quoted-printable Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable 2.2.2 is fine. It looks to me that what is not covered in the current version of 2.2.1 = is the case of these devices that are modeled in their state machine so = that the operStatus follows a adminStatus transition to down, although = no fault was detected on the respective interface. These interfaces will = never be in the state described by 2.2.2. For these cases, when = adminStatus transitions back to up is enough to re-establish operStatus = as well.=20 (I used the IETF MIB-II terminology that I am more familiar with) Regards, Dan > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On=20 > Behalf Of Sharon Chisholm > Sent: 21 November, 2003 9:35 PM > To: entmib@ietf.org > Subject: RE: [Entmib] FW: [psg.com #77] AutoReply:=20 > Operational State Disabled - correct ive action required? >=20 >=20 > Hi >=20 > Well, the difference between 2.2.1 and 2.2.2 is that one can be made > operational simply by enabling the administrative state while=20 > one requires > some corrective action AND someone to enable the=20 > administrative state. I > think this covers all the cases you are referring to. Or am I missing > something? >=20 > Sharon >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: Friday, November 21, 2003 2:13 PM > To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org > Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: Operational State > Disabled - correct ive action required? >=20 >=20 > Sharon, >=20 > You are correct about the section number. The text I was=20 > commenting on is in > Section 2.2.1 >=20 > 2.2.1 Admin State Locked, Operational State Disabled and=20 > Usage State Idle >=20 > The entity is totally inoperable, it is not servicing any entities > and it is also administratively prohibited from use. To make it > available for use, both management permission and some corrective > action are necessary. This is similar to an ifAdminStatus of down > and ifOperStatus of down. >=20 > I still believe that there is no need for a corrective action=20 > in all cases. > In some cases restoring management permission by setting=20 > the admin state to unlock should be enough. The suggested text: >=20 > The entity is totally inoperable, it is not servicing any entities > and it is also administratively prohibited from use. To make it > available for use, management permission (and in some=20 > cases corrective > action) are necessary. This is similar to an ifAdminStatus of down > and ifOperStatus of down. >=20 > Regards, >=20 > Dan >=20 >=20 >=20 > > -----Original Message----- > > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On > > Behalf Of Sharon Chisholm > > Sent: 21 November, 2003 8:38 PM > > To: entmib@ietf.org > > Subject: [Entmib] FW: [psg.com #77] AutoReply: Operational=20 > > State Disabled - correct ive action required? > >=20 > >=20 > > Hi > >=20 > > Proposed Resolution to ent-state-77: > >=20 > > Actually, I believe what you are describing is in section 2.2.2. > >=20 > > I propose that no change is required as a result of this comment. > >=20 > >=20 > > -----Original Message----- > > From: entity-state [mailto:rt+entity-state@rt.psg.com] > > Sent: Tuesday, July 15, 2003 4:24 AM > > To: Chisholm, Sharon [CAR:0S00:EXCH] > > Subject: [psg.com #77] AutoReply: Operational State Disabled=20 > > - corrective > > action required? > >=20 > > > >=20 > > -------------------------------------------------------------- > > ----------- > > Romascanu, Dan (Dan) [dromasca@avaya.com] > >=20 > > "Section 2.2.1 in [in version 01]- A corrective action is not > > necessary=20 > > in all cases to make an entity available for use. In some=20 > > cases setting=20 > > the admin state to unlock should be enough." > >=20 > > _______________________________________________ > > Entmib mailing list > > Entmib@ietf.org > > https://www1.ietf.org/mailman/listinfo/entmib > >=20 >=20 > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib >=20 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Sat Nov 22 13:19:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17924 for ; Sat, 22 Nov 2003 13:19:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANcLU-0006ZS-R6; Sat, 22 Nov 2003 13:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANcLT-0006ZH-E6 for entmib@optimus.ietf.org; Sat, 22 Nov 2003 13:18:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17913 for ; Sat, 22 Nov 2003 13:18:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANcLR-0000kX-00 for entmib@ietf.org; Sat, 22 Nov 2003 13:18:57 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ANcLR-0000kK-00 for entmib@ietf.org; Sat, 22 Nov 2003 13:18:57 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAMIIKK19300 for ; Sat, 22 Nov 2003 13:18:20 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 22 Nov 2003 13:18:20 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954E552@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Sat, 22 Nov 2003 13:18:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Hmmm. The problem is then that there are two different ways to interpret the state of the entity by reading the same values for those three objects. I'd suggest one of the following then 1) Always force people to use the states as described. Then even if the internal state model is as you described, the externally visible behaviour would be as described in section 2.2. 2) Support two behaviours for oper state and provide a type object to tell you which one is being used. These would be INTEGER { operIndependentAdmin, operFollowsAdmin (2) }. I'm not sure about this approach, but I suspect it would make some people happy. Sharon -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Friday, November 21, 2003 2:53 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? 2.2.2 is fine. It looks to me that what is not covered in the current version of 2.2.1 is the case of these devices that are modeled in their state machine so that the operStatus follows a adminStatus transition to down, although no fault was detected on the respective interface. These interfaces will never be in the state described by 2.2.2. For these cases, when adminStatus transitions back to up is enough to re-establish operStatus as well. (I used the IETF MIB-II terminology that I am more familiar with) Regards, Dan > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On Behalf Of > Sharon Chisholm > Sent: 21 November, 2003 9:35 PM > To: entmib@ietf.org > Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: > Operational State Disabled - correct ive action required? > > > Hi > > Well, the difference between 2.2.1 and 2.2.2 is that one can be made > operational simply by enabling the administrative state while one > requires some corrective action AND someone to enable the > administrative state. I > think this covers all the cases you are referring to. Or am I missing > something? > > Sharon > > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Friday, November 21, 2003 2:13 PM > To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org > Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: Operational State > Disabled - correct ive action required? > > > Sharon, > > You are correct about the section number. The text I was commenting on > is in Section 2.2.1 > > 2.2.1 Admin State Locked, Operational State Disabled and Usage State > Idle > > The entity is totally inoperable, it is not servicing any entities > and it is also administratively prohibited from use. To make it > available for use, both management permission and some corrective > action are necessary. This is similar to an ifAdminStatus of down > and ifOperStatus of down. > > I still believe that there is no need for a corrective action in all > cases. In some cases restoring management permission by setting > the admin state to unlock should be enough. The suggested text: > > The entity is totally inoperable, it is not servicing any entities > and it is also administratively prohibited from use. To make it > available for use, management permission (and in some cases > corrective > action) are necessary. This is similar to an ifAdminStatus of down > and ifOperStatus of down. > > Regards, > > Dan > > > > > -----Original Message----- > > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On Behalf > > Of Sharon Chisholm > > Sent: 21 November, 2003 8:38 PM > > To: entmib@ietf.org > > Subject: [Entmib] FW: [psg.com #77] AutoReply: Operational > > State Disabled - correct ive action required? > > > > > > Hi > > > > Proposed Resolution to ent-state-77: > > > > Actually, I believe what you are describing is in section 2.2.2. > > > > I propose that no change is required as a result of this comment. > > > > > > -----Original Message----- > > From: entity-state [mailto:rt+entity-state@rt.psg.com] > > Sent: Tuesday, July 15, 2003 4:24 AM > > To: Chisholm, Sharon [CAR:0S00:EXCH] > > Subject: [psg.com #77] AutoReply: Operational State Disabled > > - corrective > > action required? > > > > > > > > -------------------------------------------------------------- > > ----------- > > Romascanu, Dan (Dan) [dromasca@avaya.com] > > > > "Section 2.2.1 in [in version 01]- A corrective action is not > > necessary in all cases to make an entity available for use. In some > > cases setting > > the admin state to unlock should be enough." > > > > _______________________________________________ > > Entmib mailing list > > Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib > > > > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib > _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Sat Nov 22 14:05:12 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17925 for ; Sat, 22 Nov 2003 13:19:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANcLV-0006Zv-Ji for entmib-archive@odin.ietf.org; Sat, 22 Nov 2003 13:19:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAMIJ1Zs025269 for entmib-archive@odin.ietf.org; Sat, 22 Nov 2003 13:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANcLU-0006ZS-R6; Sat, 22 Nov 2003 13:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANcLT-0006ZH-E6 for entmib@optimus.ietf.org; Sat, 22 Nov 2003 13:18:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17913 for ; Sat, 22 Nov 2003 13:18:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANcLR-0000kX-00 for entmib@ietf.org; Sat, 22 Nov 2003 13:18:57 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ANcLR-0000kK-00 for entmib@ietf.org; Sat, 22 Nov 2003 13:18:57 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAMIIKK19300 for ; Sat, 22 Nov 2003 13:18:20 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 22 Nov 2003 13:18:20 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340954E552@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Sat, 22 Nov 2003 13:18:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Hmmm. The problem is then that there are two different ways to interpret the state of the entity by reading the same values for those three objects. I'd suggest one of the following then 1) Always force people to use the states as described. Then even if the internal state model is as you described, the externally visible behaviour would be as described in section 2.2. 2) Support two behaviours for oper state and provide a type object to tell you which one is being used. These would be INTEGER { operIndependentAdmin, operFollowsAdmin (2) }. I'm not sure about this approach, but I suspect it would make some people happy. Sharon -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Friday, November 21, 2003 2:53 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? 2.2.2 is fine. It looks to me that what is not covered in the current version of 2.2.1 is the case of these devices that are modeled in their state machine so that the operStatus follows a adminStatus transition to down, although no fault was detected on the respective interface. These interfaces will never be in the state described by 2.2.2. For these cases, when adminStatus transitions back to up is enough to re-establish operStatus as well. (I used the IETF MIB-II terminology that I am more familiar with) Regards, Dan > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On Behalf Of > Sharon Chisholm > Sent: 21 November, 2003 9:35 PM > To: entmib@ietf.org > Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: > Operational State Disabled - correct ive action required? > > > Hi > > Well, the difference between 2.2.1 and 2.2.2 is that one can be made > operational simply by enabling the administrative state while one > requires some corrective action AND someone to enable the > administrative state. I > think this covers all the cases you are referring to. Or am I missing > something? > > Sharon > > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Friday, November 21, 2003 2:13 PM > To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org > Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: Operational State > Disabled - correct ive action required? > > > Sharon, > > You are correct about the section number. The text I was commenting on > is in Section 2.2.1 > > 2.2.1 Admin State Locked, Operational State Disabled and Usage State > Idle > > The entity is totally inoperable, it is not servicing any entities > and it is also administratively prohibited from use. To make it > available for use, both management permission and some corrective > action are necessary. This is similar to an ifAdminStatus of down > and ifOperStatus of down. > > I still believe that there is no need for a corrective action in all > cases. In some cases restoring management permission by setting > the admin state to unlock should be enough. The suggested text: > > The entity is totally inoperable, it is not servicing any entities > and it is also administratively prohibited from use. To make it > available for use, management permission (and in some cases > corrective > action) are necessary. This is similar to an ifAdminStatus of down > and ifOperStatus of down. > > Regards, > > Dan > > > > > -----Original Message----- > > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On Behalf > > Of Sharon Chisholm > > Sent: 21 November, 2003 8:38 PM > > To: entmib@ietf.org > > Subject: [Entmib] FW: [psg.com #77] AutoReply: Operational > > State Disabled - correct ive action required? > > > > > > Hi > > > > Proposed Resolution to ent-state-77: > > > > Actually, I believe what you are describing is in section 2.2.2. > > > > I propose that no change is required as a result of this comment. > > > > > > -----Original Message----- > > From: entity-state [mailto:rt+entity-state@rt.psg.com] > > Sent: Tuesday, July 15, 2003 4:24 AM > > To: Chisholm, Sharon [CAR:0S00:EXCH] > > Subject: [psg.com #77] AutoReply: Operational State Disabled > > - corrective > > action required? > > > > > > > > -------------------------------------------------------------- > > ----------- > > Romascanu, Dan (Dan) [dromasca@avaya.com] > > > > "Section 2.2.1 in [in version 01]- A corrective action is not > > necessary in all cases to make an entity available for use. In some > > cases setting > > the admin state to unlock should be enough." > > > > _______________________________________________ > > Entmib mailing list > > Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib > > > > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib > _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Mon Nov 24 16:03:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29663 for ; Mon, 24 Nov 2003 16:03:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONrJ-0001G4-Ma; Mon, 24 Nov 2003 16:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONr3-0001FP-SK for entmib@optimus.ietf.org; Mon, 24 Nov 2003 16:02:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29600 for ; Mon, 24 Nov 2003 16:02:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONr2-0004df-00 for entmib@ietf.org; Mon, 24 Nov 2003 16:02:44 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AONr1-0004d9-00 for entmib@ietf.org; Mon, 24 Nov 2003 16:02:43 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAOL2Bt29701 for ; Mon, 24 Nov 2003 16:02:11 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Nov 2003 16:02:10 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34095D4A3C@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Mon, 24 Nov 2003 16:02:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Entmib] FW: [psg.com #78] AutoReply: Collection of Editorial Comments Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Proposed Resolution to ent-state-78: Replace all instances of "entity MIB" with "Entity MIB" Every time an enumeration name is used within a description, it will be quoted - 'unsupported' for example. In section 2, replace " The goal in adding state objects to the Entity MIB [RFC2737] is to define a useful subset of the possible state attributes that could be tracked for a given entity that both fit into the existing IETF model, as well as leveraged existing well-deployed models. " With " The goal in adding state objects to the Entity MIB [RFC2737] is to define a useful subset of the possible state attributes that could be tracked for a given entity that both fit into the state models such as those used in the Interfaces MIB [RFC2863] as well as leverage existing well-deployed models. " In section 2.1 replace "Physical entities exist within a containment hierarchy. This raises some interesting issues not addresses in existing work on state management [X.731]." With "Physical entities exist within a containment hierarchy. This raises some interesting issues not addressed in existing work on state management [X.731]." In section 2.2 replace "describes what each of these combinations of states means. It also compare this combination of states to that of the ifAdminStatus and" With "describes what each of these combinations of states means. It also compares this combination of states to that of the ifAdminStatus and " In section 2 replace " capacity to serve additional users. In the context of this MIB, the user is equivalent to an entity, so this term us substituted." With " capacity to serve additional users. In the context of this MIB, the user is equivalent to an entity, so this term is substituted." In section 2.2 replace " The Interfaces MIB [RFC2863] defines the ifAdminStatus object, which has status of up, down and testing and the ifOperStatus object, which has states of up, down, testing, unknown, dormant, notPresent and lowerLayerDown." With " The Interfaces MIB [RFC2863] defines the ifAdminStatus object, which has states of up, down and testing and the ifOperStatus object, which has states of up, down, testing, unknown, dormant, notPresent and lowerLayerDown." Delete section 2.3 (Physical Classes and States" and ensure that the descriptions of the objects are sufficiently clear. I'm not sure which key word is not capitalized in section 2.4 (item B12) In the definition of AlarmStatus replace: " warning (6), -- Not defined in X.731 indeterminate (7) -- Not defined in X.731 " With " -- The following are Not defined in X.731 warning (6), indeterminate (7) " Add in new Intellectual Property section as follows: "The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, July 15, 2003 4:29 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #78] AutoReply: Collection of Editorial Comments ------------------------------------------------------------------------- Romascanu, Dan (Dan) [dromasca@avaya.com] "Editorial Comments B1) Intellectual Property section is missing B2) Entity MIB and entity MIB are capitalized in an un-consistent manner in the document. I suggest to use Entity MIB all over, starting with the Abstract section. B3) What is the 'existing IETF model' mentioned in the first paragraph of Section 2? B4) Also in the first paragraph in Section 2, replace 'leveraged' by 'leverage'. B5) Section 2.1, first paragraph - replace 'addresses' by 'addressed' B6) Section 2.2 'compares' instead of 'compare' B7) I understand that 'state' and 'status' are interchangeable in this document, but from a style point of view, the same noun should be used in the same phrase. See second paragraph in 2.2 B8) All section 2.3 should be better organized. The way it is written, it is not clear why some values are being omitted. It would be useful to re-write it in a tabular manner, and be specific what values are relevant for each entPhysicalType and each object. B9) replace 'chassis' by 'container' B10) 2.3.5.2 is incomprehensible B11) 2.3.9.1, 2.3.9.2 - replace 'system' by 'stack'. B12) 2.4. - key word not capitalized B13) several DESCRIPTION clauses in the MIB would gain in readability if enumerated value significance is written in separated lines" Juergen Schoenwaelder [schoenw@ibr.cs.tu-bs.de] 'a) Typo in section 2: "so this term us substituted". b) Typo in section 2.1: "interesting issues not addresses in existing work" c) Typo in section 2.2: "It also compare this combination of states" ' ' e) entStatAdmin is actually entStateAdmin ' Subrahmanya Hegde [subrah@cisco.com]: Convention followed in many RFC MIBs is : The enumeration name used in the DESCRIPTION should be specified in quotes 'disabled' 'unsupported' etc. In my opinion, it will increase the readability. Is it possible you make these editorial changes? _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Mon Nov 24 16:03:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29674 for ; Mon, 24 Nov 2003 16:03:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONrK-0001HN-H8 for entmib-archive@odin.ietf.org; Mon, 24 Nov 2003 16:03:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOL32Bu004913 for entmib-archive@odin.ietf.org; Mon, 24 Nov 2003 16:03:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONrJ-0001G4-Ma; Mon, 24 Nov 2003 16:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONr3-0001FP-SK for entmib@optimus.ietf.org; Mon, 24 Nov 2003 16:02:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29600 for ; Mon, 24 Nov 2003 16:02:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONr2-0004df-00 for entmib@ietf.org; Mon, 24 Nov 2003 16:02:44 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AONr1-0004d9-00 for entmib@ietf.org; Mon, 24 Nov 2003 16:02:43 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAOL2Bt29701 for ; Mon, 24 Nov 2003 16:02:11 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Nov 2003 16:02:10 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34095D4A3C@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Mon, 24 Nov 2003 16:02:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Entmib] FW: [psg.com #78] AutoReply: Collection of Editorial Comments Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Proposed Resolution to ent-state-78: Replace all instances of "entity MIB" with "Entity MIB" Every time an enumeration name is used within a description, it will be quoted - 'unsupported' for example. In section 2, replace " The goal in adding state objects to the Entity MIB [RFC2737] is to define a useful subset of the possible state attributes that could be tracked for a given entity that both fit into the existing IETF model, as well as leveraged existing well-deployed models. " With " The goal in adding state objects to the Entity MIB [RFC2737] is to define a useful subset of the possible state attributes that could be tracked for a given entity that both fit into the state models such as those used in the Interfaces MIB [RFC2863] as well as leverage existing well-deployed models. " In section 2.1 replace "Physical entities exist within a containment hierarchy. This raises some interesting issues not addresses in existing work on state management [X.731]." With "Physical entities exist within a containment hierarchy. This raises some interesting issues not addressed in existing work on state management [X.731]." In section 2.2 replace "describes what each of these combinations of states means. It also compare this combination of states to that of the ifAdminStatus and" With "describes what each of these combinations of states means. It also compares this combination of states to that of the ifAdminStatus and " In section 2 replace " capacity to serve additional users. In the context of this MIB, the user is equivalent to an entity, so this term us substituted." With " capacity to serve additional users. In the context of this MIB, the user is equivalent to an entity, so this term is substituted." In section 2.2 replace " The Interfaces MIB [RFC2863] defines the ifAdminStatus object, which has status of up, down and testing and the ifOperStatus object, which has states of up, down, testing, unknown, dormant, notPresent and lowerLayerDown." With " The Interfaces MIB [RFC2863] defines the ifAdminStatus object, which has states of up, down and testing and the ifOperStatus object, which has states of up, down, testing, unknown, dormant, notPresent and lowerLayerDown." Delete section 2.3 (Physical Classes and States" and ensure that the descriptions of the objects are sufficiently clear. I'm not sure which key word is not capitalized in section 2.4 (item B12) In the definition of AlarmStatus replace: " warning (6), -- Not defined in X.731 indeterminate (7) -- Not defined in X.731 " With " -- The following are Not defined in X.731 warning (6), indeterminate (7) " Add in new Intellectual Property section as follows: "The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, July 15, 2003 4:29 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #78] AutoReply: Collection of Editorial Comments ------------------------------------------------------------------------- Romascanu, Dan (Dan) [dromasca@avaya.com] "Editorial Comments B1) Intellectual Property section is missing B2) Entity MIB and entity MIB are capitalized in an un-consistent manner in the document. I suggest to use Entity MIB all over, starting with the Abstract section. B3) What is the 'existing IETF model' mentioned in the first paragraph of Section 2? B4) Also in the first paragraph in Section 2, replace 'leveraged' by 'leverage'. B5) Section 2.1, first paragraph - replace 'addresses' by 'addressed' B6) Section 2.2 'compares' instead of 'compare' B7) I understand that 'state' and 'status' are interchangeable in this document, but from a style point of view, the same noun should be used in the same phrase. See second paragraph in 2.2 B8) All section 2.3 should be better organized. The way it is written, it is not clear why some values are being omitted. It would be useful to re-write it in a tabular manner, and be specific what values are relevant for each entPhysicalType and each object. B9) replace 'chassis' by 'container' B10) 2.3.5.2 is incomprehensible B11) 2.3.9.1, 2.3.9.2 - replace 'system' by 'stack'. B12) 2.4. - key word not capitalized B13) several DESCRIPTION clauses in the MIB would gain in readability if enumerated value significance is written in separated lines" Juergen Schoenwaelder [schoenw@ibr.cs.tu-bs.de] 'a) Typo in section 2: "so this term us substituted". b) Typo in section 2.1: "interesting issues not addresses in existing work" c) Typo in section 2.2: "It also compare this combination of states" ' ' e) entStatAdmin is actually entStateAdmin ' Subrahmanya Hegde [subrah@cisco.com]: Convention followed in many RFC MIBs is : The enumeration name used in the DESCRIPTION should be specified in quotes 'disabled' 'unsupported' etc. In my opinion, it will increase the readability. Is it possible you make these editorial changes? _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib