RE: [Entmib] Mini WG LAST CALL:draft-ietf-entmib-state-06.txt
"Sharon Chisholm" <schishol@nortelnetworks.com> Sun, 23 January 2005 19:31 UTC
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02948 for <entmib-archive@lists.ietf.org>; Sun, 23 Jan 2005 14:31:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsnQJ-0007QU-BZ; Sun, 23 Jan 2005 14:29:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsnOy-0007Cs-NR for entmib@megatron.ietf.org; Sun, 23 Jan 2005 14:28:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02739 for <entmib@ietf.org>; Sun, 23 Jan 2005 14:27:59 -0500 (EST)
Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsnfK-0000Wo-NB for entmib@ietf.org; Sun, 23 Jan 2005 14:44:55 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j0NJRSU04841 for <entmib@ietf.org>; Sun, 23 Jan 2005 14:27:28 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <YZADJ9KV>; Sun, 23 Jan 2005 14:27:29 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4025A1C0E@zcarhxm2.corp.nortel.com>
From: Sharon Chisholm <schishol@nortelnetworks.com>
To: entmib@ietf.org
Subject: RE: [Entmib] Mini WG LAST CALL:draft-ietf-entmib-state-06.txt
Date: Sun, 23 Jan 2005 14:27:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78
X-BeenThere: entmib@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Entity MIB WG <entmib.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/entmib>, <mailto:entmib-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:entmib@ietf.org>
List-Help: <mailto:entmib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/entmib>, <mailto:entmib-request@ietf.org?subject=subscribe>
Sender: entmib-bounces@ietf.org
Errors-To: entmib-bounces@ietf.org
Done. -----Original Message----- From: entmib-bounces@ietf.org [mailto:entmib-bounces@ietf.org] On Behalf Of Margaret Wasserman Sent: Friday, January 21, 2005 8:48 AM To: j.schoenwaelder@iu-bremen.de Cc: entmib@ietf.org Subject: Re: [Entmib] Mini WG LAST CALL:draft-ietf-entmib-state-06.txt Thanks, Juergen! These comments are clear and actionable, and addressing them will certainly improve the quality of the document. Sharon, can you do a quick spin to make these changes, and we will submit the resulting document to the IESG? Thanks, Margaret At 4:07 PM +0100 1/19/05, Juergen Schoenwaelder wrote: >On Sun, Jan 16, 2005 at 08:00:01AM -0500, Margaret Wasserman wrote: > >> The Entity State MIB has also been updated to address the issues >> raised in WG Last Call (see below). I've reviewed this document, and >> it seems to contain the changes that were agreed on the list. >> >> This document has also been through several WG Last Calls and should >> be ready for submission to the IESG for Proposed Standard. >> >> So, if you have any objections to submitting this document to the >> IESG for publication as a Proposed Standard RFC, please send them to >> the entmib@ietf.org mailing list by Wednesday, January 19th. > >I have checked <draft-ietf-entmib-state-06.txt> and I support the >document being submitted to the IESG. I have some editorial nits that >probably should be addressed before submitting the document to that the >IESG to reduce confusion/trouble/delay later on. > >- IANA Considerations section is missing. See the MIB guidelines > document about what to put there. > >- Reference [RFC2737] should probably be referring to the updated > ENTITY-MIB (or at least a comment to the RFC Ed. concerning this > should be added). > >- Citations such as [Alarm-MIB] should be replaced with [RFC3877]. > >- The following sentence in section 3.2. does not read well: > > [...] If there are active alarms, then > the alarmActiveTable in the Alarm MIB [Alarm MIB] should be searched > for alarmActiveResourceId that match this entPhysicalIndex. > > Here is a first proposal to improve the wording: > > [...] If there are active alarms, then > the alarmActiveTable in the Alarm MIB [RFC3877] should be searched > for rows whose alarmActiveResourceId matches this entPhysicalIndex. > > I think it is important to be clear that there can be multiple > matching rows. > >- The following sentence in section 3.2. is probably not quite right: > > Alternatively, if the alarmActiveTable is queried first and an > active alarm with a value of alarmActiveResourceId that matches > this entPhysicalIndex is found, then entStateAlarm can be used to > quickly determine if there are additional active alarms against > this physical entity. > > My understanding is that entStateAlarm allows me to detect what kind > of alarms I have but not how many. So if there are multiple alarms > of the same severity, then entStateAlarm will not really allow me to > detect that "there are additional active alarms against this physical > entity". > > Alternatively, if the alarmActiveTable is queried first and an > active alarm with a value of alarmActiveResourceId that matches > this entPhysicalIndex is found, then entStateAlarm can be used to > quickly determine if there are additional active alarms with a > different severity against this physical entity. > >- Security considerations: > > I suggest to insert "(entStateAdmin)" into the first sentence > directly after "management object" and remove the second paragraph. > > In addition, I suggest to move the last and next to last paragraph > directly below the first paragraph in this section so that the MIB > specific stuff stays together and is not mixed with the more general > "why you should use SNMPv3" statement. > > Putting things together, I suggest the following text for the > security considerations section: > > There is one management object (entStateAdmin) defined in this MIB > that has a MAX-ACCESS clause of read-write. The object may be > considered sensitive or vulnerable in some network environments. > The support for SET operations in a non-secure environment without > proper protection can have a negative effect on network operations. > > Note that setting the entStateAdmin to 'locked' or 'shuttingDown' > can cause disruption of services ranging from those running on a > port to those on 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. > > SNMP versions prior to SNMPv3 did not include adequate security. > Even if the network itself is secure (for example by using IPSec), > even then, there is no control as to who on the secure network is > allowed to access and GET/SET (read/change/create/delete) the > objects in this MIB module. > > It is RECOMMENDED that implementers consider the security features > as provided by the SNMPv3 framework (see [RFC3410], section 8), > including full support for the SNMPv3 cryptographic mechanisms (for > authentication and privacy). > > Further, deployment of SNMP versions prior to SNMPv3 is NOT > RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to > enable cryptographic security. It is then a customer/operator > responsibility to ensure that the SNMP entity giving access to an > instance of this MIB module is properly configured to give access to > the objects only to those principals (entities) that have legitimate > rights to indeed GET or SET (change/create/delete) them. > >/js > >-- >Juergen Schoenwaelder International University Bremen ><http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 >Bremen, Germany > >_______________________________________________ >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
- RE: [Entmib] Mini WG LAST CALL:draft-ietf-entmib-… Sharon Chisholm