Re: 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 [email protected] 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
>[email protected]
>https://www1.ietf.org/mailman/listinfo/entmib