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