Re: [Entmib] Mini WG LAST CALL:draft-ietf-entmib-state-06.txt
Margaret Wasserman <margaret@thingmagic.com> Fri, 21 January 2005 13:59 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 IAA11522 for <entmib-archive@lists.ietf.org>; Fri, 21 Jan 2005 08:59: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 1CrzDr-0006vn-Mb; Fri, 21 Jan 2005 08:53:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crz9h-0006GX-3c for entmib@megatron.ietf.org; Fri, 21 Jan 2005 08:48:55 -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 IAA10282 for <entmib@ietf.org>; Fri, 21 Jan 2005 08:48:51 -0500 (EST)
Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrzPa-0003Z4-Bh for entmib@ietf.org; Fri, 21 Jan 2005 09:05:18 -0500
Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 265436; Fri, 21 Jan 2005 08:47:30 -0500
Mime-Version: 1.0
Message-Id: <p06200708be16b84c11dc@[192.168.2.2]>
In-Reply-To: <20050119150727.GA2807@james>
References: <200501042031.PAA15747@ietf.org> <p06200717be1013d727c6@[192.168.2.2]> <20050119150727.GA2807@james>
Date: Fri, 21 Jan 2005 08:48:11 -0500
To: j.schoenwaelder@iu-bremen.de
From: Margaret Wasserman <margaret@thingmagic.com>
Subject: Re: [Entmib] Mini WG LAST CALL:draft-ietf-entmib-state-06.txt
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
Cc: entmib@ietf.org
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
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] I-D ACTION:draft-ietf-entmib-state-06.txt Internet-Drafts
- [Entmib] Mini WG LAST CALL:draft-ietf-entmib-stat… Margaret Wasserman
- Re: [Entmib] Mini WG LAST CALL:draft-ietf-entmib-… Juergen Schoenwaelder
- Re: [Entmib] Mini WG LAST CALL:draft-ietf-entmib-… Margaret Wasserman